>>> Ken Gaillot <[email protected]> schrieb am 15.01.2018 um 17:51 in 
>>> Nachricht
<[email protected]>:
> 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...

Regards,
Ulrich



_______________________________________________
Users mailing list: [email protected]
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

Reply via email to