[ClusterLabs] Opinions wanted: another logfile question for Pacemaker 2.0
Klaus Wenninger
kwenning at redhat.com
Mon Jan 15 12:14:01 EST 2018
On 01/15/2018 06:08 PM, Klaus Wenninger wrote:
> On 01/15/2018 05:51 PM, Ken Gaillot wrote:
>> Currently, Pacemaker will use the same detail log as corosync if one is
>> specified (as "logfile:" in the "logging {...}" section of
>> corosync.conf).
>>
>> The corosync developers think that is a bad idea, and would like
>> pacemaker 2.0 to always use its own log.
>>
>> Corosync and pacemaker both use libqb to write to the logfile. libqb
>> doesn't have any locking mechanism, so there could theoretically be
>> some conflicting writes, though we don't see any in practice.
>>
>> Does anyone have a strong opinion on this one way or the other? Do you
>> like having pacemaker and corosync detail messages in one logfile, or
>> would you prefer separate logfiles?
> I'm aware that a log-entry from one source (like corosync) appearing
> before an entry from another source (like pacemaker) doesn't necessarily
> mean that this correctly reflects their sequence in time but usually
> it is working fairly well.
> With timestamps of 1 second granularity in 2 files we would be definitely
> off worse.
> Please correct me if timestamping is configurable already but if not
> I would say we should either have at least the possibility to log into
> a single file or we should have timestamping with a granularity at
> least 3 magnitudes finer. (configurable timestamps as in pacemaker-alerts
> might be a solution)
Moving the time-handling-code from pacemaker to libqb anyway might not
be a bad idea.
Sorry for answering my own posts ;-)
Klaus
>
> Regards,
> Klaus
>
>> Note that this question only applies to the detail log; the syslog
>> would still get messages from everything (when configured).
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://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
More information about the Users
mailing list