Re: Minor HEADSUP - "New order" for newsyslog

At 12:56 PM -0700 6/13/04, Wes Peters wrote:
>On Saturday 12 June 2004 13:48, Garance A Drosehn wrote:
>>
>>  In the new order, it:
>>       finds all log files which need to be rotated
>>       rotates *all* files which needed to be rotated
>>       sends ONE signal to each daemon or process group which
>>          is related to any file that had to be rotated.
>>       waits 10 seconds (after all signals are sent)
>>       does a gzip/bzip2 on each newly-rotated blah.0 file, and
>>          after each one does the appropriate chown/chmod/chflag
>>          calls.  (note that it does not fork off multiple
>>          concurrent tasks to do these compressions, so it always
>>          behaves as if the 'W' flag has been specified).
>>
>>  Assuming I have not made any bugs, the end result should be the
>>  same as the end-result in the oldorder, it's just that things
>>  are done in a safer order
>
>What happens if a new rotate request for a logfile appears
>before the gzip/bzip2 for the existing .0 file has completed,
>or even started?  We have encountered this a number of times
>with a runaway process babbling into a log.

My guess is that *if* a second rotate happens before the first
one finishes, then this neworder-change will have the same issues
as you see with the oldorder.  My hope is that it will be much
less likely that you will see this happen with the neworder.

With the old order, you would see at least a 10-second delay for
each file that needs to be rotated.  With the neworder, there is a
1-second delay for each *process* that is signalled, followed by a
single 10-second delay.  And then it tries to compress files as
quickly as it can, although it does do it sequentially instead of
forking off separate processes for each one.  On a run which finds
many log files which need to be rotated, the new order should
complete much quicker than the old order.  (on one sample config
file that I was looking at, the time saved could be as much as
fifteen minutes!).

Assuming newsyslog is only run once-per-hour, I think you should
should be better off with the new order.  If this issue still comes
up, then change the syslog.conf entry to run newsyslog with '-v',
and append it's output to some other log file.  Then send me the
output and the matching config file, and I will see if I can think
up some solution for that problem.

One possible solution is to go with a time-related prefix for
files after they are rotated.  There is one PR with a sample
implementation of that, and I also have my own implementation
in mind.  I do intend to provide that as an option, one way or
another...

One scenario where that issue could certainly happen is if the
config file has multiple entries for a single file.  I do not
know if you do that, but there are cases where that might be
reasonable to do.  I do intend to improve how newsyslog works
with multiple entries for a single file, but I have not started
on that yet.  I have no idea if many people actually use that.

With your setup, is it possible that you will EVER rotate any
particular file more than once in a single hour?  (if so, then
I should plan for that...)

-- 
Garance Alistair Drosehn     =      gad_at_gilead.netel.rpi.edu
Senior Systems Programmer               or   gad_at_FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA