Another off-topic question (using this forum as your author page is quite discouraging about sending you emails ....)
What's the reason for naming cyclog files with the time they were closed? (other than that's how djb did it?), since this information is available easily with 'ls -l'?
I use a logger that opens a $CREATE_TIMESTAMP.u file, and makes "current" a symbolic link to it; and on close renames it to ".s", which I find more intuitive and informative (also provides time between log creation and first message, which is unavailable with cyclog). I was considering changing the ".u"/".s" marking to be an attribute (-w or +i or +t to signify "safely closed") to help repeated rsyncs of log directories, but haven't done that yet.
I'm sure there's some useful aspect of existing cyclog/multilog behaviour that I'm missing, but I haven't been able to figure what it is for the last 10 years ...
If you want more than just my perspective, look to Laurent Bercot's Supervision Mailing list. M. Bercot is of course there, as well as a few other people.
As for the filenames, yes the original reason was for compatibility with multilog, and of course all of the other tools that can process these log directories. I did set out, after all, to produce a cyclog workalike, with lessons from multilog incorporated. Note that said tools might not deal well with log directories where the same log file is available via two names, both "current" and something else.
Moreover, if you go and look at follow-log-directories you can see an additional benefit that it very efficiently skips its cursors over old files without having to look at their i-nodes because it knows that the filename is guaranteed to be a timestamp at or after the last log entry in the file.
Furthermore, if you go and read the cyclog manual, you'll find out why using the w permission bit had problems. (-:
> Moreover, if you go and look at follow-log-directories you can see an additional benefit that it very efficiently skips its cursors over old files without having to look at their i-nodes because it knows that the filename is guaranteed to be a timestamp at or after the last log entry in the file.
Thanks, that's two thing I've missed (because I never used it, I guess ..): This optimization and follow-log-directories+export-to-rsyslog which was introduced at a time I wasn't looking :)
> Furthermore, if you go and read the cyclog manual, you'll find out why using the w permission bit had problems. (-:
:) Indeed, thanks.
> 1.41 is building up changes, by the way.
Thanks! And since I've missed follow-log-directories (and export-to-rsyslog) before, maybe there's another tool I've missed that would make shipping log directories more efficient? I'm concerned with very-low-bandwidth, very-intermittently-connected servers in which rsync is a godsend and e.g. rsyslog and friends proved much less reliable and efficient; And the renaming of "current" makes it miss the fact that it already has an (almost complete) copy of said file under a different name.
I don't know off the top of my head, but then I don't know all of the tools that exist for multilog/cyclog log directories.
This is, of course, more of an rsync problem. And it seems that there are approaches to having rsync detect renamed files and handle them more efficiently.
Another off-topic question (using this forum as your author page is quite discouraging about sending you emails ....)
What's the reason for naming cyclog files with the time they were closed? (other than that's how djb did it?), since this information is available easily with 'ls -l'?
I use a logger that opens a $CREATE_TIMESTAMP.u file, and makes "current" a symbolic link to it; and on close renames it to ".s", which I find more intuitive and informative (also provides time between log creation and first message, which is unavailable with cyclog). I was considering changing the ".u"/".s" marking to be an attribute (-w or +i or +t to signify "safely closed") to help repeated rsyncs of log directories, but haven't done that yet.
I'm sure there's some useful aspect of existing cyclog/multilog behaviour that I'm missing, but I haven't been able to figure what it is for the last 10 years ...