double 'ctlinnd flushlogs' deletes news, errlog

[Florian Schlichting]

Hi Julien,

> >Perhaps innd should stop do the .old rotation and restrict itself to
> >flushing, and scanlogs should mv to .old rather than cp, and not just
> >"in case innd is down", and then the first invocation of 'ctlinnd
> >flushlogs' can be deleted?
> 
> That's a possibility.  But shouldn't "news" and "errlog" then
> treated like what is done for live files just below?  (using a
> symbolic link rather than a copy)

I'm not sure why the livefiles are rotated using hard links, that is,
why it is necessary to make absolutely sure that at no time does the
regular log file not exist. To my limited knowledge, if a file is opened
for writing that does not exist, it is created, period. That's the way
e.g. logrotate works: it moves the current log file out of the way,
while the daemon is still writing to it. Then it sends sighup, the
daemon finishes writing and reopens (creates) the new log file. The day
after, the old logfile is being compressed.

> A point to take into account:  changing the "flushlogs" behaviour
> would not be possible in the STABLE 2.5 branch, but only in 2.6...
> so the bug you report will still be present.

it may be better to revert the commit that introduced the second call to
flushlogs, then - after all, the issue it corrects is fairly minor.

> Another possibility, suggested by the TODO file:
> 
> * ctlinnd flushlogs currently renames all of the log files.  It would be
> nice to support the method of log rotation that most other daemons
> support, namely to move the logs aside and then tell innd to reopen its
> log files.  Ideally, that behavior would be triggered with a SIGHUP.
> scanlogs would have to be modified to handle this.

this is what I suggest

> 
> The best way to support this seems to be to leave scanlogs as is by
> default, but also add two additional modes.  One would flush all the
> logs and prepare for the syslog logs to be rotated, and the other would
> do all the work needed after the logs have been rotated.  That way, if
> someone wanted to plug in a separate log rotation handler, they could do
> so and just call scanlogs on either side of it.  The reporting portions
> of scanlogs should be in a separate program.

While I support splitting reporting off scanlogs, let scanlogs do log
rotation only and support plugging in other log rotation handlers, I'd
think this is a separate issue.

But I don't understand why two "modes" should be needed. This seems
overly complex, for no benefit?

scanlogs:
 moves news file
 moves errlog file
 does livefile rotation
 calls flushlogs

innd
 ICDwrite (flush history, articles in the storage manager, and active)
   does NOT rename the news file
 reopen the news file
   does NOT rename the errlog file
 reopen the errlog file
 flush exploder and process channels

scanlogs
 goes on to summarize log files, call innreport, compress and rotate OLD
 logs


Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5565 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20130416/c6e5ede3/attachment.bin>