[ClusterLabs] Corosync 3 release plans?
ccaulfie at redhat.com
Thu Sep 27 11:09:46 EDT 2018
On 27/09/18 16:01, Ken Gaillot wrote:
> On Thu, 2018-09-27 at 09:58 -0500, Ken Gaillot wrote:
>> On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote:
>>> Christine Caulfield <ccaulfie at redhat.com> writes:
>>>> 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
>>>> to go with a consensus on this though
>>> Yes, to do a proper job logrotate has to have a way to get the log
>>> reopened. And applications can't do that without support from
>>> I understood Honza right.
>> There are two related issues:
>> * Issue #142, about automatically rotating logs once they reach a
>> certain size, can be done with logrotate already. If it's a one-time
>> thing (e.g. running a test with trace), the admin can control
>> directly with logrotate --force /etc/logrotate.d/whatever.conf. If
>> desired permanently, a maxsize or size line can be added to the
>> logrotate config (which, now that I think about it, would be a good
>> idea for the default pacemaker config).
>> * Issue #239, about the possibility of losing messages with
>> copytruncate, has a widely used, easily implemented, and robust
>> solution of using a signal to indicate reopening a log. logrotate is
>> then configured to rotate by moving the log to a new name, sending
>> signal, then compressing the old log.
> Regarding implementation in libqb's case, libqb would simply provide
> the API for reopening the log, and clients such as pacemaker would
> intercept the signal and call the API.
That sounds pretty easy to achieve. I'm also looking into high-res
timestamps for logfiles too.
> A minor complication is that pacemaker would have to supply different
> logrotate configs depending on the version of libqb available.
Can't you just intercept the signal anyway and not do anything if an old
libqb is linked in?
More information about the Users