[ClusterLabs] Antw: Opinions wanted: another logfile question for Pacemaker 2.0

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Tue Jan 16 02:54:11 EST 2018

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 15.01.2018 um 17:51 in Nachricht
<1516035094.5232.9.camel at redhat.com>:
> 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.

I don't know libqb, but for a multi-threaded project needing debug messages, I had solved the problem by writing the log messages to a datagram socket, and one consumer received the messages from the socket, writing them to a log file. It seems the socket synchronizes the individual log messages if they are short enough (i.e. could be sent as one "packet"). Interestingly when I switched to stream sockets, individual messages mixed in the log file.

> 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 think it all depends on the amount of messages: If there are rather few, a central log file would be helpful; if there are tons of messages, separate files would be preferrable (with their own logrotate cycles). Then a tool to "combine" individual log files (from multiple nodes) chronologically stil lcould be very useful.

> Note that this question only applies to the detail log; the syslog
> would still get messages from everything (when configured).

But don't flood it with too many messages...


More information about the Users mailing list