CTDB Logging: File or syslog?

[Martin Schwenke]

On Wed, 28 Jan 2015 21:24:13 +0100, Michael Adam <obnox at samba.org>
wrote:

> On 2015-01-28 at 21:19 +0100, Michael Adam wrote:
> > On 2015-01-28 at 12:26 -0600, José A. Rivera wrote:
> > > Hey list,
> > > 
> > > I've heard that for production scenarios it is sensible to use syslog for
> > > CTDB logging because CTDB doesn't handle log rotation very well (it doesn't
> > > use SIGHUP for that?).
> > 
> > ctdb does not react to sighup or any other signal the way
> > other daemons do, i.e. with reopening its log files.
> > There is no function to reopen the log files at all.
> > I.e. for all I know, the log file is only ever opened at
> > startup time.
> > But external log rotation usually moves the log file and
> > sends the process some signal, which won't have an effect
> > here, i.e. ctdb will happily continue logging to the renamed
> > log file.
> > 
> > And there is no internal log rotation (as with samba's .old
> > mechanism either), so afaik, ctdb will fill all disk space
> > that is available.
> > 
> > The only workaround would be to copy the logfile
> > instead of moving it and then truncating the original
> > log file. But you will lose a few bytes with every
> > rotation.
> 
> I forgot to say that at least I would love to see a
> reopen-logs / SIGHUP mechanism implemented in ctdb,
> since I personally greatly prefer file logging.

Instead of implementing this in CTDB, the approach here would be to
switch to using Samba's debug.[ch] file logging directly.  Then we get
the rotation for free and we have even less duplicated code.

Blocking this is CTDB's use of debug_extra, where the string value of
that variable is prefixed to every log message.  I think that we should
be able to replace this by using logging classes... but this is quite a
bit of work so would need a chunk of time.

peace & happiness,
martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150129/b1233c46/attachment.pgp>