On 27/09/18 12:52, Ferenc Wágner wrote: > Christine Caulfield <ccaul...@redhat.com> writes: > >> I'm looking into new features for libqb and the option in >> https://github.com/ClusterLabs/libqb/issues/142#issuecomment-76206425 >> looks like a good option to me. > > It feels backwards to me: traditionally, increasing numbers signify > older rotated logs, while this proposal does the opposite. And what > happens on application restart? Do you overwrite from 0? Do you ever > jump back to 0? It also leaves the problem of cleaning up old log files > unsolved...
The idea I had was to look for logs with 'old' numbers at startup and then start a new log with the next number, starting at 0 or 1. Good point about the numbers going the other way with logrotate though, I hadn't considered that > >> Though adding an API call to re-open the log file could be done too - >> I'm not averse to having both, > > Not addig log rotation policy (and implementation!) to each application > is a win in my opinion, and also unifies local administration. Syslog > is pretty good in this regard, my only gripe with it is that its time > stamps can't be quite as precise as the ones from the (realtime) > application (even nowadays, under systemd). And that it can block the > log stream... on the other hand, disk latencies can block log writes > just as well. > TBH I would be quite happy to leave this to logrotate but the message I was getting here is that we need additional help from libqb. I'm willing to go with a consensus on this though Chrissie _______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org