monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] Unix sockets v2 and more... [was Re: [Patch] Alternativ get_


From: Jan-Henrik Haukeland
Subject: Re: [Patch] Unix sockets v2 and more... [was Re: [Patch] Alternativ get_RFC1123date...]
Date: 29 Jul 2002 16:07:54 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

Christian Hopp <address@hidden> writes:

> I have made a "create_generic_socket" function in net.c to be fed with
> a Port_T.  I tidied up validate.c which no longer needs to know with
> kind of socket it is, by have in an address (human readable
> destination) entry in Port_T with is inserted in the logfile instead.

The first impression is that this looks nice! Just what I hoped for :)

> And now for something completely different...
> 
> * The pidfile of monit should be configurable via conffile.  It also
>   makes coding much easier. (-:

I does? Is this a feature others on this list would like to see?

> * Something hypothetical: Monit runs (thats not hypothetical (-: )

B-)

>   and it checks a pidfile or tests the md5 of a file and those files
>   are on a mounted NFS... and network breaks... then monit is
>   blocked until network is back.  I know it's not wise to put server
>   stuff on the net and esp. pids and so on (if it is mounted hard
>   you cant even wake it up). But it's just a thought of mine... to
>   think about.

We can think about it and hope that no-one will actually use a mounted
director to write pid-files too or start systems daemons from. It
sounds as you says like a particulary unwise thing to do :) But that
doesn't mean that it's not an idea to have some sort of timeout in
monit. We already have it for connection tests and we can just move
the timeout code farther up in validate.c like:

void validate() {
  
  Process_T p;
 
  for ( p= processlist; p; p= p->next) {

    if (do_timeout())
        goto next;
    
    do_validate(p);
    
    next:
    alarm(0);
    
  }
  
}

-- 
Jan-Henrik Haukeland



reply via email to

[Prev in Thread] Current Thread [Next in Thread]