mail.log rotation

[wpwood3]

Originally Posted by till

We will have a look at this. Falko already added it to the bugtracker.

This issue shows "not a bug" in the bugtracker.

How can this be? All of my maillog files only show entries from 23:59 to 04:06. There is most certainly a problem!

[falko]

I've reopened it again.

[jbravo]

One question related:
Is it safe to logrotate /var/log/mail.ispconfigsave file and still have all mail statistics?

[falko]

Yes, that's no problem.

[jbravo]

Originally Posted by falko

Yes, that's no problem.

Should i insert some postrotate job? It seems to me that this log file is used only by cronscript so it is not needed.

[xrat]

Originally Posted by jbravo

Should i insert some postrotate job? It seems to me that this log file is used only by cronscript so it is not needed.

This is right. No postrotate job is needed. Of course, the rotation should not be done while the ISPconfig cron job is running, which should be at midnight. HTH.

[make-fun]

Hi folks,

unfortunatly I did not find this thread earlier and so far I can only confirm that this is also a problem with Ubuntu 6.06 (perfect setup) and ISPConfigVersion: 2.2.21
http://www.howtoforge.com/forums/sho...698#post114698

Cheers

[Morons]

Hi people, I have implemented a quick and very effective workaround for the broken logrotation on all my Ubuntu boxes, I have the last 2 Ubuntu versions all upgraded to latest via apt-get. It also make sure the postgrey does not die on me. Perhaps this posting may help Postgrey users to solve the constant dying issues on Ubuntu.

In crontab

22 06 * * * /bin/kill -9 `/usr/bin/pgrep postgrey-check.rc`
37 06 * * * echo "Daily logrotation." >/root/boot-reason
38 06 * * * /sbin/shutdown -r now

Note: The idea is to "fix" the broken parts of the logrotation, therefore killing my own checking scripts before the logrotation at 23 06 and restarting the stuff after logrotation, yes in this case via re-boot witch helps a lot. I have an mail sent to me each time the server statrup with the reason given the content of an file called "/root/boot-reason". this way all my scripts etc can send me notes if they re-started the server and for what reason.

First the Postgrey Fix
in the file postgrey-check.rc i have

#!/bin/bash
LOGFILE=/var/log/syslog
(
while read ans
do
        DUMMY=
done
#echo "Going to main loop"
while :
do
        read ans
        if [ "$ans" = "" ]
        then
                sleep 1
        else
                problem=`echo $ans | grep 'Server configuration problem'`
                if [ "$problem" != "" ] && grep "$problem" $LOGFILE > /dev/null
                then
                /usr/sbin/invoke-rc.d postgrey restart
                /usr/sbin/invoke-rc.d postfix restart
                echo 'Postgrey broken!' 2>&1 |/usr/bin/mailx -s "`uname -n` Postgrey And Postfix re-started" root@domain.tld
                fi
        fi
done
) < $LOGFILE

Note: I loop through the logfile constantly grep for the error, then imediatly act! As this does not reboot the server I have to mail myself some message of this error occuring. The funny thing is since I actually re-boot the server just after each log-rotation Postgrey never have issues. Apearently Postgrey run into file access rights on Ubuntu after logrotation, I cannot confirm this but it does seem so. After re-booting Postgrey re-start properly.

Now the Startup
In the file /etc/rc.local

cat /root/boot-reason 2>&1 |/usr/bin/mailx -s "`uname -n` Server restarted" root@domain.tld
echo "No reason given" >/root/boot-reason
/usr/bin/postgrey-check.rc >/dev/null &

to get mailx use apt-get install mailx

[falko]

I think I've finally fixed the log rotation problem in ISPConfig.
The fix will be available with the next ISPConfig version.

[xrat]

This is good news Can you say a word or two about how you approached it?