As silent now no longer only controls the generation of log messages, a better
name is required. This changes its name, inverts its value to reflect the new
name and adds a documentation comment.
Since commit d9010c7b9f, ActivateItems no
longer uses the WorkQueue upq to perform tasks but instead performs
these locally. One instance of `upq.Join()`/`upq.HasExceptions()`
remained in the function, but I believe this was just missed when
removing the `upq.Enqueue()` call just before.
This commit removes the corresponding parameter and updates all call
sites accordingly.
Introduce `-DInternal.DebugWorkerDelay=120` and sleep inside `RunWorker()`.
Rationale: With 2.11 we've introduced a real umbrella process where the
main process is spawned as child fork. Running icinga2 in foreground on
a macOS shell with LLDB will now exit, and not follow the child process.
LLDB doesn't support `follow-fork-mode child` like GDB and therefore we
need to:
- Print the child process PID
- Sleep for X seconds to allow the developer to run `lldb -p <PID>`, set breakpoints, etc.
This commit also documents all available debug build enabled internal constants.
Icinga processes check si_pid on IPC signals to ensure that the signal
comes from an expected process. OpenBSD doesn't currently fill in si_pid
in siginfo (leaving it 0) so signals never pass this check, resulting
in startup failing to complete (the worker doesn't see the umbrella's
signal and vice-versa) - issue #7505.
Relax the requirement so that either 0 or the wanted pid is accepted.
This partially reverts #7150 and avoids exceptions
inside the flow. Each time an empty active stage
is detected, Icinga tries to repair it from the
the given directory tree.
Also, the code now takes into account that it should
create the package storage on startup, whether within
the API object, or if disabled, inside the application.
Caching the active stages for packages in memory
only is in effect with the API feature being enabled.
This is useful for other deployed config packages,
not only the internal one.
fixes#7173
refs #7150
refs #7119fixes#6959
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.