RE: no webserver restart on reload

[martin rueegg [metaworx rueegg]]

> On Behalf Of Jan-Henrik Haukeland
> Sent: Donnerstag, 18. August 2005 14:17

> 
> On 18. aug. 2005, at 12.10, martin rueegg [metaworx rueegg] wrote:
> 
> > when reloading monit, the webserver is restarted. during this
> > time, no other client can connect to the daemon, that's
> > obvious. the problem is, that the client will not be able to
> > connect and therefore fail entirely with it's command.
> >
> > could it be done the way that httpd is only restared if it's
> > configuration is affected by the reload. otherwise it will
> > only temporaryly disable the handling of requests by
> > returning a http status code of 503 with a retry-after
> > <configurable value>.
> 
> Not a bad idea, but the problem is that after a restart the 
> HTTP port  
> could be changed in the control file so we MUST restart the http- 
> server thread in case we now must bind to a different port number.  
> Otherwise, this would be a good solution.

right.

> > the monit client on the other hand should retry to send his
> > request upon reception of a 503 status code for n-times where
> > n is again a <config value> (or in monitrc or as a command
> > line option).
> 
> Again, since the HTTP port number could be changed, the monit client  
> also must re-read the control file and cannot retry against the same  
> port.

right.

> I think you must solve this problem outside of monit or change your  
> own copy of monit. What you suggest is certainly possible to do in  
> monit if the HTTP port number never changes.

ok, I see the problems. following thoughts:

could some parameters be defined as unchangeable within a life cycle of 
a monit process? eg.
- set init
- set pidfile
- set statefile
- set httpd port
- ssl enable | disable
- pemfile
- address

if you need to change theese values, then the daemon needs to be 
restarted (kill -9 perserves the state).

I don't see, where the given values would be changed while having 
the need to keep the same process. I find this would be acceptable 
since it does not make any difference in the above cases but it 
would avoid that commands from a client get lost.

martin.