Multiple Nagios proccesses running.

[Chris Wilson]

Hi Andreas,

> Rather than exiting if it finds a process running with the same pid, it 
> should try and kill it (using SIGTERM, sleeping 5 seconds and then 
> issuing SIGKILL). This is because we can't be sure WHAT process it 
> found, just that it has the same pid as the one that used to be nagios, 
> and on a restart attempt where the previous daemon failed to exit the 
> logical thing to do is to re-read the configuration.

You're right that we can't identify whether the other process is, but
killing it sounds much worse than just aborting! What if the user is
running several daemons as the same UID (e.g. nobody, daemon) and
another one gets the PID that Nagios was using before?

Surely it's safer to abort so that the user finds out something is
wrong, checks for and removes the old Nagios process, and then deletes
the lockfile? It's at least better than the current behaviour (on Linux
at least) of silently carrying on :-)

But if you insist that killing the other process is the right thing to
do, I will implement it.

>  This is ofcourse 
> assuming we are checking the pid as non-root (I assume we are, as you 
> include EPERM in your exception handling). Oherwise we might be killing 
> apache, postfix or some other system service that's supposed to be running.

We have already dropped privileges by the time daemon_init() is called.

> There are also C++ style comments which need to be removed, and Ethan 
> won't accept it unless you un-wrap all the lines.

OK, I think I've fixed these issues in the attached patch. Please let me
know what you think. Thank you!

Cheers, Chris.
-- 
(aidworld) chris wilson | chief engineer (chris at aidworld.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nagios-lockfile-3.patch
Type: text/x-patch
Size: 1481 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/users/attachments/20050811/7c0e6b43/attachment.bin>