Re: restart behavior (initscript)

On Thu, Aug 07, 2003 at 11:03:59AM -0400, Jim Knoble wrote:
> Circa 2003-08-06 22:09:20 -0500 dixit Mark Hatle:
> 
> : This is my interpretation of the spec.. so it very well may be wrong.
> : 
> : Ademar de Souza Reis Jr. wrote:
> : > (i) The daemon (sshd in my case) is misconfigured, so
> : >     after stopping it, it will not (re)start.
> : >
> : >     Can I check for the presence of this scenario and refuse
> : >     to stop the service in the first place?
> : 
> : I'd consider this an undefined situation, however my feeling would be a 
> : stop followed by an aborted start.  The end result is the daemon has 
> : been stopped and an error message/status code sent to the user.
> 
> I don't see why a restart shouldn't be atomic, i.e., all-or-nothing,
> especially for important system services like sshd.

I agree that it could be atomic, and I'm about to change our internal
policy to *enforce* that behavior when possible.

If it's a consensus, It would be nice to add a note like this to the "Init
Script Actions" document (sorry for not providing a patch):

"A restart can be atomic, i.e. if the service can not be started after a
stop, a restart can return an error refusing to stop the service in the
first place."

> 
> : >(ii) When the daemon (sshd again) receives a SIGHUP, it spawns a
> : >     new copy of itself and kills the old parent process, but the
> : >     childs are kept alive.
> : >
> : >     Since there's a new parent process (the one who accepts
> : >     new connections), can I consider this the same of a
> : >     restart?

...

I don't see any reason to forbid this behavior, but since it looks
like it's a little controversial, I'll just "silently allow" it :)

Thanks.

-- 
Ademar de Souza Reis Jr. <[email protected]>

^[:wq!