Re: runit-1.0.0 release

[Alejandro Mery <amery@geeks.cl>]

Gerrit Pape wrote:

>On Thu, Feb 12, 2004 at 06:15:10PM -0300, Alejandro Mery wrote:
>  
>
>>i'm using runit on a ROCKLinux, (something betwen LFS and gentoo, but
>>it's crossplatform and your final product is an installable ISO
>>instead of a running system), here nothing else than runit itself stop
>>me to drop 100% sysvinit.
>>
>>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.
killall is at psmisc so no problem with it.
shutdown, last, lastb, mesg and wall are usefull administrative tools
bin/pidof is not need needed in pure supervised enviroment but... (see
fghack)

>>missing tools from daemontools like fghack (damn nullmailer) and to
>>    
>>
>
>Which ones beside fghack?  I personally don't use fghack, as it doesn't
>allow the service to be controlled through signals like other services.
>Instead of using fghack, the daemon really should be adapted, or as a
>workaround started from stage 1.
>  
>
fghack.... i haven't get an answer from nullmailer people and no time
yet to trace it. i agree that those daemons has to be addapted but
sometimes you don't have access to the source of the 'buggy' program or
you just don't know how to fix it (e.g. me and perl based daemons)
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?
moving them to stage 1 can follow a bad migration due to dependencies.

a workaround i did use was to loop forever after running it and
pidof/kill on ./finish, but pidof is not part of runit, so i would need
to 'fake' it using ps/grep/cut what's not optimal. (browsing /proc is a
worse idea for a ./finish)

>>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.
there is a change to fix svwaitdown to signal grandsons after the
timeout, give them $t to suicide and if they still alive annihilate
their whole family and continue stage 3? .oO( that can be misunderstood
out of context )

>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

>Regards, Gerrit.
>  
>
Regards,
Alejandro Mery