Courier isn't logging directly to the logfile--it's syslogd that's doing it.
After changing log files you have to send a SIGHUP to syslogd to get it to
stop using the old file handle or inode.
I don't know which OS you're running, but Solaris runs /usr/lib/newsyslog from
cron to rotate the logs. If /var/log/maillog isn't a standard log file then
you have to edit newsyslog to rotate it, also. You'll see newsyslog signals
syslogd after rotating the logs.
William
Geo wrote:
Is there a way to force the courier process(es) to stop using their current
logfile and cycle to a new one? Or is this a function of the system's normal
syslog mechanism? The problem is this....
I've had a couple instances where something whacked happens with courier,
and the logfile (/var/log/maillog) spins wildly out of control trying to log all
the crap courier is sending it. The last one I had went to 7Gig in size inside
of about 3 hours. So, I stopped the courier processes, removed the logfile,
and then restarted courier.
Result: courier isn't logging at all. Its almost like it holds open a handle to
that particular file, and doesn't let it go until you reboot. This is further
supported by the following:
1) stop courier
2) RENAME logfile
3) restart courier
Guess what: it still uses the RENAMED file as its log. Whacky.
Any insight anyone could provide would be great.
Regards,
- ZJ