Re: NFS is going down, et al [was: pidfiles aka. Re: [CVS] unix socket support added]

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> The alarm signal is still evaluated... but later!  So as I told you
> a NFS halted processes can't be woken up by anything.

Ouch! I would love to know the inner technical reason for this. I
guess I will have to start reading up on RPC and NFS.

> > You're in an excellent position to test this then :) I'm beting you a
> > bottle of beer that alarm will work.
> 
> Our address is on our web page. (-: But for me something
> non-alcoholic, please!

Beer or nothing I'm afraid :) So we can't expect to see you in the
crowd, the next Beer festival in October then?

> > This could be solved if I ever get around to hack the process
> > status code I was planning to do (see item 6. in the next release
> > plan). Maybe you would like to give it a stab?
> 
> I think I can do it.  I already took a look into the /proc access in
> Linux and Solaris.  It's gonna be quite OS dependent.  I will give it
> a generic frame work to access it OS independent, or can anyone
> recommend me a good lib for it, but the backend is different on
> esp. Linux and Solaris.

I was planing to look into libgtop which seems to be a usefull library
for this.

  http://www.redhat.com/swr/i386/libgtop-devel-1.0.12-8.i386.html

Maybe this library will give you a good start? It's GPL and I was
further planing to do some creative cut-and-past to create a mini
package for usage in monit. The reason is that I don't want monit to
depend on axillary libraries and users should _not_ have to download
such libraries separately. One of the best things with monit (IMO) is
that it's a compact little program without a bunch of pluggins, extra
libraries and stuff - it's just one program with a good comprehensive
configuration file. 

-- 
Jan-Henrik Haukeland