double 'ctlinnd flushlogs' deletes news, errlog

Julien ÉLIE julien at trigofacile.com
Wed Apr 24 20:34:42 UTC 2013


Hi Florian,

>>> 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
for logrotate.

    http://blog.adityapatawari.com/2012/05/logrotate-most-basic-log-management.html

"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,
> period

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?
> 
> 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

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)
files.
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?

-- 
Julien ÉLIE

« Je suis adroit de la main gauche et je suis gauche de la main
  droite. » (Raymond Devos)


More information about the inn-workers mailing list