This basically drops the "corked" implementation which just stalled the
TLS IO polling after some requests. If you need sort of rate limiting
for these events, use an external TLS proxy which terminates that in front
of Icinga.
fixes#6635
Examples:
```
globals["abc"]
globals.def
```
The patch for the Icinga Director unfortunately only solves the
master, and as discussed with @lippserd we need to ensure that
satellites and clients with 2.10 can be restarted without any errors
from deployed configuration.
refs #6509
refs icinga/icingaweb2-module-director#1654
This reverts commit c8dcd1297f6d0be8685c5a3079e40fc44e779add.
We cannot do this during application startup, since Daemonize()
kills the threads again.
refs #6514
refs #6630
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).
Precedence as follows:
- DEnvironment=...
- const Environment = ...
- object IcingaApplication "app" { environment = "..." }
The wrapped script constant handling is required
since we cannot directly link from libremote (SNI handling)
to libicinga where the object resides. Instead we'll
use the Application class helpers for hiding the ScriptGlobal
calls.
