[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