icinga2.service used `-e ${ICINGA2_ERROR_LOG}`, but this is documented
as having no effect without `-d`. Furthermore, icinga2 under systemd
unconditionally logged everything to the system log (but without setting
the log level etc), which contradicted the documentation. (Issue #6339)
Stop icinga2 on systemd from logging to stdout - and hence the system log -
once it has finished starting up. Just like when you start icinga2 from a
terminal using `-d`. And just like -d, we stop logging fatal errors to
stderr, and instead write to the log file passed with `-e`.
As per docs, mainlog (icinga2.log) is already enabled by default. And
pre-startup messages including config errors will still appear in the
system log.
This uses a new option --close-stdio, which has the same effect on logging as
--daemonize, but does not fork or call setsid().
For this purpose, I moved setsid() up and into Daemonize().
Consequence of that last point: if anyone is weird enough to specify a TTY
device file as the fatal error log (-e option), that will become icinga's
controlling terminal, which you generally don't want as a daemon. This
makes it consistent with the existing behaviour for icinga mainlog. For
this reason you're supposed to use O_NOCTTY in Linux daemons. But I wasn't
sure where icinga would want to put the ugly `#ifdef _WIN32 ... #else ...`.
Standardize on exit() / _exit() (this depends whether we are considered
to be the "main" fork, which should run anything registered with atexit()).
Exclude `return false` and throwing exceptions.
This fixes the error path for fork(). Daemonize() would return false, but
the `return false` error convention was not tested in the caller.
It also fixes the error message for fork() to show the error code.
Everyone loves `strace`, but sysadmins should not have to rerun their
daemons under it just to see an error code.
Also in case an exception is thrown, show its diagnostic information
instead of dropping it on the floor. In the log message, I mention why we
are uninitializing and then initializing the app at this point.
For the reader, it pushes all the weirdness into the error convention of
Daemonize(). This comes back to the exit() / _exit() distinction. Once
we have forked, we technically don't want to allow the parent process to
exit(), so we don't want to return to the caller.
It's called "Console", which would be line-buffered anyway. But, it's
implemented as std::cout. This might be piped to a logger, as in
daemontools or systemd. In this case it will not be a TTY, and log lines
should be flushed without too much delay. Let's just flush each message.
Let's not introduce a static instance of StreamLogger (flushed by interval
timer). That's too stressful to read, because static instances are really
annoying to order. Example citation: "Yay, our static destructors are
pretty much beyond repair at this point." -- application.cpp.
I don't know if there will be any need to optimize logging syscalls. The
init script uses `--daemonize`. I think the systemd service should also
avoid using the "Console" log after startup (see next commit). The
documentation does not warn that the syslog feature is less efficient
in system calls than mainlog; deferred flusing does not seem to be a highly
prominent feature. There's no cool comment in the code about how much the
syscalls were slowing down some use case (or qualifying that this
optimization can only eliminate syscalls on platforms with both mutexes and
clocks that can work without syscalls).
Michael Friedrich
Jean Flach
Jean Flach
Markus Frosch
Jeon Sang Wan
Gunnar Beutner
Alan Jenkins
Noah Hilverling
Michal Petko
Gunnar Beutner