CTDB Logging: File or syslog?

[Michael Adam]

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.

Michael

> However I was just pointed to the following bit of
> doc in master:
> 
>                  Under heavy loads syslog(3) can block if the syslog
>                  daemon processes messages too slowly.  This can
>                  cause CTDB to block when logging.
> 
>                  If METHOD is specified then it specifies an
>                  extension that causes logging to be done in a
>                  non-blocking mode.  Note that <emphasis>this may
>                  cause messages to be dropped</emphasis>.
> 
> Are there distinct use cases where one logging mechanism is prefferred over
> the other? Is there a general recommendation for high-activity use cases?
> 
> --Jose
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150128/cd13b633/attachment.pgp>