[ClusterLabs] Corosync 3 release plans?

Christine Caulfield ccaulfie at redhat.com
Thu Sep 27 08:19:02 EDT 2018


On 27/09/18 12:52, Ferenc Wágner wrote:
> Christine Caulfield <ccaulfie at 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



More information about the Users mailing list