On 26/09/18 09:21, Ferenc Wágner wrote: > Jan Friesse <jfrie...@redhat.com> writes: > >> wagner.fer...@kifu.gov.hu writes: >> >>> triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common >>> choices, but logging.* cmap keys probably fit Corosync better). That >>> would enable proper log rotation. >> >> What is the reason that you find "copytruncate" as non-proper log >> rotation? I know there is a risk to loose some lines, but it should be >> pretty small. > > Yes, there's a chance of losing some messages. It may be acceptable in > some cases, but it's never desirable. The copy operation also wastes > I/O bandwidth. Reopening the log files on some external trigger is a > better solution on all accounts and also an industry standard. > >> Anyway, this again one of the feature where support from libqb would >> be nice to have (there is actually issue opened >> https://github.com/ClusterLabs/libqb/issues/239). > > That's a convoluted one for a simple reopen! But yes, if libqb does not > expose such functionality, you can't do much about it. I'll stay with > syslog for now. :) In cluster environments centralised log management is > a must anyway, and that's annoying to achieve with direct file logs. >
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. Though adding an API call to re-open the log file could be done too - I'm not averse to having both, Chrissie >>> Jan Friesse <jfrie...@redhat.com> writes: >>> >>>> No matter how much I still believe totemsrp as a library would be >>>> super nice to have - but current state is far away from what I would >>>> call library (= something small, without non-related things like >>>> transports/ip/..., testable (ideally with unit tests testing corner >>>> cases)) and making one fat binary looks like a better way. >>>> >>>> I'll made a patch and send PR (it should be easy). >>> >>> Sounds sensible. Somebody can still split it out later if needed. >> >> Yep (and PR send + merged already :) ) > > Great! Did you mean to keep the totem.h, totemip.h, totempg.h and > totemstats.h header files installed nevertheless? And totem_pg.pc could > go as well, I guess. > _______________________________________________ Users mailing list: Users@clusterlabs.org https://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