double 'ctlinnd flushlogs' deletes news, errlog
julien at trigofacile.com
Wed Apr 24 20:34:42 UTC 2013
>>> 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 be
>> 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.
I believe it is for the same reason why the "copytruncate" option exists
"Copytruncate comes handy in the situation where process writes to the inode
of the log and rotating the log might cause process to go defunct or stop
logging or a bunch of other issues. Copytruncate copies the log and the further
processing is done on the copy. It also truncates the original file to zero bytes.
Therefore the inode of the file is unchanged and process keeps on writing
to the log file as if nothing has happened."
> if a file is opened for writing that does not exist, it is created,
Maybe this behaviour is not true on all platforms, and the "copytruncate"
feature is more portable for handling log rotation.
>> 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.
Yes, we could do that for INN 2.5.4.
>> 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.
> But I don't understand why two "modes" should be needed. This seems
> overly complex, for no benefit?
> moves news file
> moves errlog file
> does livefile rotation
> calls flushlogs
> 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
> goes on to summarize log files, call innreport, compress and rotate OLD
It seems strange that the rotation of the news and errlog files is done
before flushing these log files. ICDwrite() also flushes these two (buffered)
Whence the suggestion of 'ctlinnd prerotatelogs' (flushing everything),
doing the rotation with scanlogs, and 'ctlinnd postrotatelogs' (reopening
the log files and flushing exploder and process channels).
Hmmm... Shouldn't then flushing these channels also be done before rotating
the log files, so as to log in the proper daily log file what belongs to it?
« Je suis adroit de la main gauche et je suis gauche de la main
droite. » (Raymond Devos)
More information about the inn-workers