[ClusterLabs] Corosync 3 release plans?
kgaillot at redhat.com
Thu Sep 27 11:32:14 EDT 2018
On Thu, 2018-09-27 at 16:09 +0100, Christine Caulfield wrote:
> 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
> > > > > willing
> > > > > to go with a consensus on this though
> > > >
> > > > Yes, to do a proper job logrotate has to have a way to get the
> > > > log
> > > > files
> > > > reopened. And applications can't do that without support from
> > > > libqb,
> > > > if
> > > > 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
> > > rotation
> > > directly with logrotate --force /etc/logrotate.d/whatever.conf.
> > > If
> > > it's
> > > 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
> > > the
> > > 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
> libqb is linked in?
Yes, but the logrotate config will need to keep the copytruncate option
or not depending on whether the new API is available. It's not too
difficult via the configure script, just reminding myself to do it :)
Ken Gaillot <kgaillot at redhat.com>
More information about the Users