Re: runit-1.0.0 release

[Gerrit Pape <pape@smarden.org>]

On Mon, Feb 16, 2004 at 07:04:40PM -0300, Alejandro Mery wrote:
> Gerrit Pape wrote:
> >On Thu, Feb 12, 2004 at 06:15:10PM -0300, Alejandro Mery wrote:
> >>i'm just waiting for the last basic tools of sysvinit, for some
> >What exactly are they?  I think runit is rather complete, you don't
> >necessarily need pidof or local login accounting.  Also sulogin is not
> >mandatory, you could also use some getty, e.g. fgetty.

> well only reboot and halt/poweroff are a must have. because they need to
> run inside stages 3 to actually do the thing.

If stage 3 exits without halting or rebooting the kernel, the runit
program should finally do this.  Did you try it out?

> >>missing tools from daemontools like fghack (damn nullmailer) and to
> >Which ones beside fghack?  I personally don't use fghack, as it doesn't

> i don't know how fghack works but can i use it to warranty the restart
> of the daemon if it crashes? can i use it to kill the daemon when needed?

Yes, it will be restarted, no, you cannot control the daemon through
signals.

> >>finily trace why runit-3 waits for ever the active ssh sessions to
> >This is a feature.  Most probably you run sshd with a log service.
> >runsv, when asked to exit, makes sure that all logs get written by the
> >log service it additionally monitors for this service.  This is one
> >reason why the service directory and the service/log directory are
> >monitored by a single supervisor with runit.
> >
> >If runsv is told to take the sshd service down, it sends a term signal
> >to the main sshd process.  The main sshd process then exits, but it has
> >spawned children for active ssh connections, and leaves them alone.  If
> >you run the sshd service with a appendant log service, the children have
> >inherited filedescriptor 1, which is connected to the log service
> >through a pipe.  The sshd/log service waits for data as long as there
> >still are processes possibly writing data; you can set a timeout through
> >svwaitdown though.
> >  
> i have...
> echo 'Waiting for services to stop...'
> svwaitdown -xk -t350 /service/*
> 
> and i got a *very* unconfortable state when one box had to reboot but it
> passed the whole weekend in stage 3 just because one damn user didn't
> close his ssh client.

Yes, I now see that this is a problem.  svwaitdown doesn't properly
complete its task.  It sends a kill signal to the service daemon after
the timeout, but doesn't stop the log service explicitly.  For daemons
like sshd that fork children which detach and demonize, there possibly
still are processes left with a file descriptor to the log pipe open.

But why is your stage 3 script still waiting?  svwaitdown has returned,
so stage 3 should continue and finally exit, causing runit to halt or
reboot the kernel.

> there is a change to fix svwaitdown to signal grandsons after the

Unfortunately sshd creates children so that the supervisor cannot know
the process ids of its grandchildren, so killing them does not work,
blame the service daemon.  But I can change svwaitdown to explicitly
take the log service down after the timeout.

For now you can run
 runsvctrl term /var/service/sshd/log
right after svwaitdown in your stage 3 script.

> >Without a sshd/log service, the behavior should change, but you lose the
> >guarantee for your log.
> as i see it i completely lost the log
Ups, how that?

Regards, Gerrit.