>
> Or have I misunderstood again? Are you suggesting that Exim should
> automatically initiate compression and rotation if it finds the logging
> disk is getting full? That wouldn't be done by _the_ Exim process, but
> by _an_ Exim process, since any Exim process can write to the log. The
> only way it could do this would be to fire up a sub-process and run
> exicyclog in it. Hmm. No. You wouldn't want to do that because several
> simultaneously running processes would tend to fire off several
> exicyclogs at the same time. It would have to be a single, long-running
> process that watched the log. I don't really fancy writing another
> separate process, and I equally don't fancy modifying the existing
> daemon to do this (see above).
>
I was suggesting that it would be done optionally, same as the 'running out
of space behaviour' I hope would be optional. Admittedly the problems of
multiple exim processes writing to the logs and therefor potentially able
to kick of a cycle hadn't occurred to me.
> It would of course be possible to write a cron script that you could run
> every so often that checked the space on the disc and ran exicyclog if
> it was getting full. However, there would have to be some safeguards
> against it running it too often (e.g. if rotation and compression didn't
> actually bring you below the threshold).
>
> Also, it occurs to me, that for both this and the original suggestion,
> it would be necessary to obey statvfs() every time anything is written
> to the log; would this be an unnecessary cost?
probably, my point was merely that if the original was worth the effort
then so probably was my idea. I use cron's myself, but am quite happy to
have things concentrated in the hands of the exim daemon which has, once set
up never given me any worries.
Julian
--
*** Exim information can be found at
http://www.exim.org/ ***
