* Implemented more robust reload methodology which basically does the
following:
* Sends a reload signal to nagios.
* Check nagios log file to confirm that it recognized the SIGHUP
signal from the reload request.
* Retry reload if the log file doesn't mention receipt of the
SIGHUP.
* Worst case: after 30 attempts, and probably a little over 1 second
per attempt, proceed anyway (but with a warning)
While in theory there could be a very small window between Nagios
receiving the SIGHUP and writing the related message to its log file,
this should be very small and unlikely to be hit.
* Replaced nested definition of "i" with "_", to avoid colliding and
since the inner loop's variable isn't actually used.
* Updated the subprocess check in _get_last_reload_message to use
shell=True.
* Implemented more robust reload methodology which basically does the
following:
* Sends a reload signal to nagios.
* Check nagios log file to confirm that it recognized the SIGHUP
signal from the reload request.
* Retry reload if the log file doesn't mention receipt of the
SIGHUP.
* Worst case: after 30 attempts, and probably a little over 1 second
per attempt, proceed anyway (but with a warning)
While in theory there could be a very small window between Nagios
receiving the SIGHUP and writing the related message to its log file,
this should be very small and unlikely to be hit.
Keep writing config for newly-created config files
With the new logic, we try to write only the files we need to.
However, there may legitimately be cases where there's multiple sets
of data associated with the same host name (e.g. multiple nrpe units),
and at present, only the first set of such data will actually be
written.
This change tracks files which are being newly created, and will allow
multiple sets of relation data to be written to the same file, if
necessary.
Deduplication is only performed if there are 2 or more related units
with the same target hostname from different models. If there are
"duplicates" but they are from the same model (e.g. multiple nrpe units
associated with different principal apps on the same host), it is
probably preferable to have those "coalesce" into a single host, rather
than having distinct records with redundant checks.
Keep writing config for newly-created config files
With the new logic, we try to write only the files we need to.
However, there may legitimately be cases where there's multiple sets
of data associated with the same host name (e.g. multiple nrpe units),
and at present, only the first set of such data will actually be
written.
This change tracks files which are being newly created, and will allow
multiple sets of relation data to be written to the same file, if
necessary.
