# Problem rotating logfiles



## xy16644 (Feb 11, 2014)

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:


```
/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.


----------



## SirDice (Feb 11, 2014)

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.


----------



## xy16644 (Feb 11, 2014)

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?



```
/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
```


----------



## SirDice (Feb 11, 2014)

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.


----------



## xy16644 (Feb 11, 2014)

I think that should do it. I'll check tomorrow morning to see if it worked!


----------



## xy16644 (Feb 12, 2014)

That didn't seem to work. I received an error email from cron with:


```
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
```


----------



## xy16644 (Feb 13, 2014)

So my change in /etc/newsyslog.conf did not help rotate the logfiles. Last night I tried the following:


```
/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.


----------



## mickey (Feb 13, 2014)

xy16644 said:
			
		

> So my change in /etc/newsyslog.conf did not help rotate the logfiles. Last night I tried the following:
> 
> 
> ```
> ...



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.


----------



## xy16644 (Feb 13, 2014)

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.


----------



## xy16644 (Feb 13, 2014)

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.


----------



## SirDice (Feb 13, 2014)

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.


----------



## mickey (Feb 13, 2014)

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.


----------



## xy16644 (Feb 13, 2014)

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):


```
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 `newsyslogd`is not meant to be used?


----------



## mickey (Feb 13, 2014)

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).


----------



## xy16644 (Feb 13, 2014)

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.


----------



## mickey (Feb 13, 2014)

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:

```
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:


```
/var/log/milter-greylist/greylist.log  postfix:postfix       644  7     *    @T00   N
```


----------



## xy16644 (Feb 13, 2014)

Many thanks for this, I have put this entry in my newsyslog.conf so I will check it again tomorrow morning and report back!


----------

