The .ti files call `DependencyGraph::AddDependency(this, service.get())`. Obviously, `service.get()` is the parent and `this` (Downtime, Notification, ...) is the child. The DependencyGraph terminology should reflect this not to confuse its future users.
The following already works:
* Custom key sizes, e.g. 2048 bits
* Custom key types, e.g. ECC
* Multiple trusted root CAs in `/var/lib/icinga2/certs/ca.crt`
* Different root CAs per cluster subtree, as long as each node trusts the
issuers of the certificates of all nodes it's directly connected to
* Any number of intermediate CAs
* Update 10-icinga-template-library.md
Explicitly name the config-sync check feature of the icinga check, as before this was a little bit too undocumented making it unknown to me.
Also mention where the check has to executed in order to bring the desired results.
* Update 15-troubleshooting.md
Add 4h typical error point for configuration stored outside of /etc/icinga2/zones.d. For when a non-distributed setup was migrated to a distributed setup.
Also link to the internal icinga CheckCommand to promote its existance.
* Update 15-troubleshooting.md
Remove "-" from link
* Revert "Update 15-troubleshooting.md"
This reverts commit bb25ba3ff5.
* Update AUTHORS
Add myself to AUTHORS
* Update doc/15-troubleshooting.md
Co-authored-by: alvar <8402811+oxzi@users.noreply.github.com>
* Update doc/10-icinga-template-library.md
Co-authored-by: alvar <8402811+oxzi@users.noreply.github.com>
* Update doc/15-troubleshooting.md
Co-authored-by: alvar <8402811+oxzi@users.noreply.github.com>
---------
Co-authored-by: alvar <8402811+oxzi@users.noreply.github.com>
Currently, for each `Disconnect()` call, we spawn a coroutine, but every
one of them is just usesless, except the first one. However, since all
`Disconnect()` usages share the same asio strand and cannot interfere
with each other, spawning another coroutine within `Disconnect()` isn't
even necessary. When a coroutine calls `Disconnect()` now, it will
immediately initiate an async shutdown of the socket, potentially causing
the coroutine to yield and allowing the others to resume. Therefore, the
`m_ShuttingDown` flag is still required by the coroutines to be checked
regularly.
For check_procs, both the Monitoring Plugins' implementation[0] and the
Nagios Plugin[1] are supporting the "-X" or "--exclude-process" flag to
exclude one or many processes by name. However, this flag is missing
here in the Icinga Template Library.
The Nagios Plugin implementation also comes with "-j" and "-g" for
FreeBSD jails and Linux cgroups, respectively. But, to keep it
compatible, I would ignore these for the moment.
Closes#10226.
[0]: https://www.monitoring-plugins.org/doc/man/check_procs.html
[1]: https://nagios-plugins.org/doc/man/check_procs.html
In fact, this is already done for the outer loop (for each bulk), just not yet for the inner one (for each message of a bulk). So once the remote signals EOF, don't try to process the remaining queue until write error (which can't be associated with a particular message anyway, due to buffering), but just let the peer go. Flush already half-written messages, though, if possible.
by not calling `std::atomic<T>::atomic(void)`.
After the latter the instance "does not contain a T object, and its only valid uses are destruction and initialization by std::atomic_init" which we don't call. So the only safe option is `std::atomic<T>::atomic(T)`.
https://en.cppreference.com/w/cpp/atomic/atomic/atomic
When the `Desconnect()` method is called, clients are not disconnected
immediately. Instead, a new coroutine is spawned using the same strand
as the other coroutines. This coroutine calls `async_shutdown` on the
TCP socket, which might be blocking. However, in order not to block
indefintely, the `Timeout` class cancels all operations on the socket
after `10` seconds. Though, the timeout does not trigger the handler
immediately; it creates spawns another coroutine using the same strand
as in the `JsonRpcConnection` class. This can cause unexpected delays if
e.g. `HandleIncomingMessages` gets resumed before the coroutine from the
timeout class. Apart from that, the coroutine for writing messages uses
the same condition, making the two symmetrical.
Something is definitely going wrong if a client tries to reconnect to
this endpoint while it still has an active connection to that client. So
we shouldn't hide this, but at least log it at info level. Apart from
that, I've added some additional information about the currently active
client, such as when the last message was sent and received.
Julian Brost
Alexander A. Klimov
Yonas Habteab
Christian Lauf
Alvar Penning
Julian Brost