Problem rotating logfiles

I am trying to rotate the logfiles for mail/milter-greylist and mail/clamav-milter but seem to be having an issue with it. Whenever the logfile is rotated both of these services are stopped. Currently I have the following in /etc/newsyslog.conf:

Code:
/var/log/milter-greylist/greylist.log  postfix:postfix       644  7     *    @T00   -     /var/run/milter-greylist.pid
/var/log/clamav/clamav-milter.log   clamav:clamav       644  7     *    @T00    -    /var/run/clamav/clamav-milter.pid

What am I doing wrong? All my other logfiles rotate fine.
 
You need to add the correct flags. Currently you've configured newsyslog(8) to send a kill(1) to the PID of the process, effectively killing it. Normally you send a SIGHUP or SIGUSR1 to the process to indicate it needs to refresh the log files.
 
SirDice said:
You need to add the correct flags. Currently you've configured newsyslog(8) to send a kill(1) to the PID of the process, effectively killing it. Normally you send a SIGHUP or SIGUSR1 to the process to indicate it needs to refresh the log files.

So this should do the trick?


Code:
/var/log/milter-greylist/greylist.log  postfix:postfix       644  7     *    @T00   U     /var/run/milter-greylist.pid
/var/log/clamav/clamav-milter.log   clamav:clamav       644  7     *    @T00    U    /var/run/clamav/clamav-milter.pid
 
Have a look in the documentation, I don't use either programs. But usually a SIGHUP is the correct signal so this should do the trick.
 
That didn't seem to work. I received an error email from cron with:

Code:
newsyslog: bad value '8126' for process number in /var/run/milter-greylist.pid
newsyslog: bad value '8182' for process number in /var/run/clamav/clamav-milter.pid
newsyslog: bad value '8142' for process number in /var/run/clamav/clamd.pid
newsyslog: bad value '8165' for process number in /var/run/clamav/freshclam.pid
 
So my change in /etc/newsyslog.conf did not help rotate the logfiles. Last night I tried the following:

Code:
/var/log/milter-greylist/greylist.log   postfix:postfix   644  7     *    @T00   -    /var/run/milter-greylist.pid 1
/var/log/clamav/clamav-milter.log   clamav:clamav       644  7     *    @T00     -    /var/run/clamav/clamav-milter.pid 1
/var/log/clamav/clamd.log       clamav:clamav           644  7     *    @T00     -    /var/run/clamav/clamd.pid 1
/var/log/clamav/freshclam.log   clamav:clamav           644  7     *    @T00     -    /var/run/clamav/freshclam.pid 1

But when I checked it this morning the milters were not running. What am I doing wrong? I'm not sure what to try next!

Running newsyslog -v doesn't give any errors.
 
xy16644 said:
So my change in /etc/newsyslog.conf did not help rotate the logfiles. Last night I tried the following:

Code:
/var/log/milter-greylist/greylist.log   postfix:postfix   644  7     *    @T00   -    /var/run/milter-greylist.pid 1
/var/log/clamav/clamav-milter.log   clamav:clamav       644  7     *    @T00     -    /var/run/clamav/clamav-milter.pid 1
/var/log/clamav/clamd.log       clamav:clamav           644  7     *    @T00     -    /var/run/clamav/clamd.pid 1
/var/log/clamav/freshclam.log   clamav:clamav           644  7     *    @T00     -    /var/run/clamav/freshclam.pid 1

But when I checked it this morning the milters were not running. What am I doing wrong? I'm not sure what to try next!

Your above newsyslog.conf looks correct. Specifying the signal number is redundant though, as newsyslog will use SIGHUP by default when no signal number is given.

So the question is, where do these log files come from? If they are managed by syslogd, then there is no need to send any signal whatsoever to these processes. If the log files are managed by the corresponding processes themselves, then you need to check the documentation of clamd, freshclam, clamav-milter and milter-greylist whether they support re-reading config files and/or re-opening log files upon receipt of a SIGHUP signal at all. Some programs use other signals than SIGHUP for this task (i.e. SIGUSR1). Only if this is the case, you will need to specify the signal number in newsyslog.conf.
 
The logfiles come from security/clamav, security/clamav-milter and mail/milter-greylist‎. As far as I can tell there are no entries for these ports in syslogd.

I've read a few web sites where other people have rotated these logfiles but their newsyslogd entries didn't work for me (although the website was a few years old so may not work on my system).

I'll keep trying but I'm unsure what to try next.
 
The logfiles come from security/clamav, security/clamav-milter and mail/milter-greylist. As far as I can tell there are no entries for these ports in syslogd.

I've read a few web sites where other people have rotated these logfiles but their newsyslogd entries didn't work for me (although the website was a few years old so may not work on my system).

I'll keep trying but I'm unsure what to try next.
 
Are you still getting those "Bad value" messages? Make sure they all write to the correct .pid file and verify if the PID that's stored in them is the correct PID of the process when it's running. The .pid files may be stale and not point to the correct processes any more.
 
I suppose the "Bad Value" messages where caused by specifying the "U" flag in newsyslog.conf, which tells newsyslog that it is a process group, but that is incorrect.
 
SirDice said:
Are you still getting those "Bad value" messages? Make sure they all write to the correct .pid file and verify if the PID that's stored in them is the correct PID of the process when it's running. The .pid files may be stale and not point to the correct processes any more.

Nah, those errors have gone since removing the "U" flag. There are some options in the /usr/local/etc/clamav-milter.conf for managing logfiles such as (this is whats in my config file currently):

Code:
LogSyslog no
LogFacility LOG_MAIL
LogFileMaxSize 5M
LogFile /var/log/clamav/clamav-milter.log
LogTime yes 
LogRotate yes

I have set the maximum size to 5M and enabled log rotate but I'm not sure if it'll rotate the logfile are just overwrite the oldest entries in the log. I'm guessing for this milter that newsyslogdis not meant to be used?
 
I suggest you remove the entries for clamav-milter and milter-greylist from your newsyslog.conf and let them handle log rotation by themselves. Alternatively you could set up logging via syslog and use newsyslog for log rotation (without specifiying the PID file).
 
Thats what I have done for clamav-milter but I couldn't find any entries in the/usr/local/etc/mail/greylist.conf for managing logfiles.
 
xy16644 said:
Thats what I have done for clamav-milter but I couldn't find any entries in the/usr/local/etc/mail/greylist.conf for managing logfiles.

Taken from http://milter-greylist.wikidot.com/readme-file:
Code:
 15 Custom logs
 ==============

It is possible to monitor milter-greylist activity with a custom log
format. You can choose where the output is sent (file or external
command), and the output format. If you have this in greylist.conf:
stat ">>/var/log/milter-greylist.log" "%T{%T}    %i:%f:%r:%S\n"

On each mail, this will give you a line like this in milter-greylist.log:
10:08:04    192.0.2.16:spammer@evil.com:postmaster@example.net:reject

Another example, to send the data to the local7 facility of syslog,
using the external command logger:
stat "|logger -p local7.info" "%i:%f:%r:%S\n" 

Substitutions are the same as in URL checks (%i becomes sender IP, %s
becomes sender e-mail, %r becomes recipient, and so on). A few nifty
additions:

%T{format} is substituted by strftime(3) time format. So %T{%F %T} gives
you a date/time in the following format: YYYY-MM-DD HH:MM:SS 
%S is substituted by the action milter-greylist chose: accept, tempfail
or reject
%A is substituted by the line number of the ACL that caused the decision
This looks like the milter-greylist.log is not kept open between writes. So it should be possible to rotate it via newsyslog without having to send a signal to any process, using a configuration line like this in your newsyslog.conf:

Code:
/var/log/milter-greylist/greylist.log  postfix:postfix       644  7     *    @T00   N
 
Many thanks for this, I have put this entry in my newsyslog.conf so I will check it again tomorrow morning and report back!
 
Back
Top