Multiple Nagios proccesses running.

[Chris Wilson]

Hi Andreas,

> To the facts. Nagios is a GNU project. Ethan gets no money for it 
> (although a great deal of appreciation), and he has only so much time. I 
> for one am quite happy that he doesn't bother with old code but instead 
> focuses on making 2.x as good as it can and should be.

Of course I'm not demanding that Ethan should maintain the old 1.x
branch, but I wish he would allow someone to do so.

> > I will try and find time to maintain it myself if
> > nobody else wants to, and it doesn't annoy anyone too much (but it would
> > be a "fork" of Nagios 1.2).
> 
> Whatever floats your dinghy. Just make sure you get Ethan's permission 
> to use the name Nagios though, or you might end up in a trademark dispute.

Does anyone else think that a "maintained" fork of 1.x is a good idea?

> > It will probably be a few years before I
> > trust 2.x enought to use it.
> 
> Your loss. It has a great deal to recommend it.

>From what I've seen on the mailing list, despite the many benefits of
the new design of 2.x, it's just not stable enough to be used in
production yet (e.g. huge memory consumption, stopping service checks
after a while). My guess is that it might take a while before it is.

> It probably won't. Ethan is adamant when it comes to not handing out CVS 
> access, and developing without it is quite fruitless. I've offered to 
> help myself. Considering I've had 20-something patches I don't think 
> it's an issue of code-quality.

Well, at least that saves me from trying fruitlessly, thanks.

> > How do you think I wrote a patch without reading the code?
> 
> Guess-work? I've seen a fair amount of it from you on other topics.

Sorry, I wasn't aware of that. Please could you give me some examples? I
would like to do better.

> mutexes are thread constructs. 1.x is a single-thread app.

I said "mutual exclusion" which is a generic term. You mentioned
mutexes, which aren't :-)

> I'll have to look at that patch. Can you send it again?

Sure, it's attached.

> I don't have high hopes though, considering the fact that you proposed 
> using the extremely non-portable setproctitle() to discern the master 
> process from the slaves.

Well, one can always #ifdef such things to platforms where they are
known to work. I wasn't aware that it wasn't portable, but I must admit
that I have only programmed C on Windows, Linux and OBSD, and only
extensively on Linux.

> How exactly do you check that the process listed isn't running? AFAIK 
> there aren't any portable syscalls available for getting the process 
> name from a pid, and the /proc filesystem works differently on different 
> platforms.

kill(pidno, 0).

> man fcntl. If a process is already holding the lock one is trying to 
> acquire it will return -1. It's the right way to do it. Checking the pid 
> and trying to find matching process is the cumbersome, incorrect and 
> non-portable way.

I read the man page. It's all very well in theory, but it's just not
working on Linux, and I don't know why yet.

Thanks for your help!

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