runit-1.0.0 release

runit-1.0.0 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hi, runit version 1.0.0 is released and available through

 http://smarden.org/runit/

runit is a cross platform UNIX init scheme with service supervision, see
the web page for details.

The documentation has been updated slightly since the latest test
package, there were no changes to the runit source code.  This is the
first stable release of runit.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: runit-1.0.0 release

[Lukas Beeler]

* Gerrit Pape <pape@smarden.org>:
> Hi, runit version 1.0.0 is released and available through

Thanks for the hard work. I've been using runit for quite some
time now, both in private and in my company. It works very well, and
your response to bug reports has always been excellent.

runit has made my life easier, and thus i would like to donate
something for your hard work. Do you have a paypal account or
similar?

I've got a little feature request too: Iam missing a replacement
for /command/tai64nlocal, which currently is the only reason why
i still have the daemontools on my boxes. Do you plan on writing
a replacement?

-- 
Today is the first day of the rest of our lives.
http://www.suug.ch

Re: runit-1.0.0 release

[Gerrit Pape]

On Wed, Feb 11, 2004 at 09:35:41AM +0100, Lukas Beeler wrote:
> * Gerrit Pape <pape@smarden.org>:
> > Hi, runit version 1.0.0 is released and available through
> 
> Thanks for the hard work. I've been using runit for quite some
> time now, both in private and in my company. It works very well, and
> your response to bug reports has always been excellent.
> 
> runit has made my life easier, and thus i would like to donate
> something for your hard work. Do you have a paypal account or
> similar?

Yes, thanks.  I get in contact with you.

> I've got a little feature request too: Iam missing a replacement
> for /command/tai64nlocal, which currently is the only reason why
> i still have the daemontools on my boxes. Do you plan on writing
> a replacement?

I don't plan to do a replacement, but I added support for human readable
timestamps to svlogd, see the -tt switch.  AFAICS they're nearly as
precise as tai64n, have the same number of chars, and also are sortable.
Hope this helps.

Regards, Gerrit.

Re: runit-1.0.0 release

[Richard A Downing FBCS]

On Tue, 10 Feb 2004 15:35:45 +0000
Gerrit Pape <pape@smarden.org> wrote:

> Hi, runit version 1.0.0 is released and available through
> 
>  http://smarden.org/runit/
> 
> runit is a cross platform UNIX init scheme with service supervision, see
> the web page for details.
> 
> The documentation has been updated slightly since the latest test
> package, there were no changes to the runit source code.  This is the
> first stable release of runit.
> 
> Regards, Gerrit.
> -- 
> Open projects at http://smarden.org/pape/.
> 

Gerrit,

I am using runit - indeed I'm trying to write up how to use it as an
alternative to the standard SysVinit boot-scripts for Linux From Scratch:
http://www.linuxfromscratch.org.

However, I'm a little stumped on the way stage 1 is managed.  The manual states
that 'If /etc/runit/1 itself crashes, runit will skip stage 2 and enter stage
3'. Can you say what exactly that means?  If I exit -1, it just reports a
warning and then enters stage 2 as normal.  I want to be able to say 'things
got too difficult in stage 1' and get straight to stage 3 and an orderly
shutdown.

Also, how would you expect a stage 1 script to provide an emergency shell?

Cheers,
Richard.

-- 
Richard A Downing FBCS http://www.109bean.org.uk/
Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: runit-1.0.0 release

[Gerrit Pape]

On Wed, Feb 11, 2004 at 07:23:55PM +0000, Richard A Downing FBCS wrote:
> I am using runit - indeed I'm trying to write up how to use it as an
> alternative to the standard SysVinit boot-scripts for Linux From
> Scratch: http://www.linuxfromscratch.org.
> 
> However, I'm a little stumped on the way stage 1 is managed.  The
> manual states that 'If /etc/runit/1 itself crashes, runit will skip
> stage 2 and enter stage 3'. Can you say what exactly that means?

runit.c uses wait_exitcode() and wait_chrashed() from the daemontools
public domain library, the wait interface is documented in the qmail
man pages:
 http://www.qmail.org/man/man3/wait.html

An exit code other than zero just causes a warning, stage 2 only is
skipped if stage 1 has crashed, e.g. due to a broken binary.  I guess
that this happened here:
 http://article.gmane.org/gmane.comp.sysutils.supervision.general/295
 http://thread.gmane.org/gmane.comp.sysutils.supervision.general/296

> If I exit -1, it just reports a warning and then enters stage 2 as
> normal.  I want to be able to say 'things got too difficult in stage
> 1' and get straight to stage 3 and an orderly shutdown.

It would be easy to change this in the runit.c source, but I'm curious
why you need it.  What's the advantage of running stage 3 in this
situation?, if stage 1 cannot recover, it can possibly reboot
immediately.

> Also, how would you expect a stage 1 script to provide an emergency
> shell?

Look at the example stage 1 scripts for FreeBSD on OpenBSD.  But maybe
the boot scripts from lfs already do that, like the Debian ones.  Debian
even provides an extra /sbin/sulogin program.

The BSDs include code for an emergency root shell with a password prompt
in process no 1.  I don't want to do this with runit, it should be a
separate program started by stage 1 if at all.

When converting a system from sysvinit to runit, this thread might be of
help:
 http://thread.gmane.org/gmane.comp.sysutils.supervision.general/243

Regards, Gerrit.

Re: runit-1.0.0 release

[Thomas Schwinge]

On Wed, Feb 11, 2004 at 07:23:33PM +0000, Richard A Downing FBCS wrote:
> I am using runit - indeed I'm trying to write up how to use it as an
> alternative to the standard SysVinit boot-scripts for Linux From Scratch:
> http://www.linuxfromscratch.org.

This was exactly the same way I was going around one and a half years
ago. :-)

Now I'm away from LFS: I am using slashpackage-foreign
<URL:http://multivac.cwru.edu./spf/> to install my packages, unifying
the power of building from source tarballs with the distincness of a
slashpackage file system layout <URL:http://cr.yp.to/slashpackage.html>.

> Also, how would you expect a stage 1 script to provide an emergency shell?

Paul Jarc - directly using svscan as a replacement for init
<URL:http://multivac.cwru.edu./svscan-1/> - has a nice solution at
<URL:http://multivac.cwru.edu./svscan-1/init>. Look for the shell
function try_().

Regards,
 Thomas

Re: runit-1.0.0 release

[Richard A Downing FBCS]

On Wed, 11 Feb 2004 20:43:12 +0000
Gerrit Pape <pape@smarden.org> wrote:

> An exit code other than zero just causes a warning, stage 2 only is
> skipped if stage 1 has crashed, e.g. due to a broken binary.  I guess
> that this happened here:
>  http://article.gmane.org/gmane.comp.sysutils.supervision.general/295
>  http://thread.gmane.org/gmane.comp.sysutils.supervision.general/296
> 
> > If I exit -1, it just reports a warning and then enters stage 2 as
> > normal.  I want to be able to say 'things got too difficult in stage
> > 1' and get straight to stage 3 and an orderly shutdown.
> 
> It would be easy to change this in the runit.c source, but I'm curious
> why you need it.  What's the advantage of running stage 3 in this
> situation?, if stage 1 cannot recover, it can possibly reboot
> immediately.

Gerrit,

I have made progress and now run a standard shell in the recovery situation,
modelling my script on the openbsd example.  I would have liked to use sulogin,
which is more secure, but as I was planning not to install sysVinit, and
sulogin is part of that package, it's out for the moment, but see below.

Next problem.  You state above that the stage 1 script can reboot immediately. 
Well, the reboot script that your openbsd example uses is also a sysVinit
script.  If I call 'init 6' (or init 0) from within stage 1, I am, of
course sending a signal to runit!  Runit doesn't accept signals in stage 1!

Catch 22?

I'm beginning to think that I'm going to have to install SysVinit after all.
(I may need wall, halt, poweroff, reboot, shutdown, and sulogin, these are all
part of sysVinit)

Cheers,
Richard.

-- 
Richard A Downing FBCS http://www.109bean.org.uk/
Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: runit-1.0.0 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

On Thu, Feb 12, 2004 at 05:41:20PM +0000, Richard A Downing FBCS wrote:
> I have made progress and now run a standard shell in the recovery
> situation, modelling my script on the openbsd example.  I would have
> liked to use sulogin, which is more secure, but as I was planning not
> to install sysVinit, and sulogin is part of that package, it's out for
> the moment, but see below.

Yes, you're right, sulogin is part of sysvinit.

> I'm beginning to think that I'm going to have to install SysVinit
> after all.  (I may need wall, halt, poweroff, reboot, shutdown, and
> sulogin, these are all part of sysVinit)

I still have the sysvinit package on my systems, and use some of its
tools.  It's very difficult to remove the 'essential' package sysvinit
from a Debian system, even if runit is used as init scheme, because
other essential packages depend on sysvinit directly (e.g. dpkg).

A halt and reboot program actually is very simple; but beware, it simply
reboots or halts the kernel and doesn't care about the system's state.
If you use it from stage 1, you should exactly know the system's state
as /etc/runit/1 is the first and only process started since process no 1.

I attach a sample 'reboot.c' source file.  Put it into
/package/admin/runit/compile/, change to this directory, add this to
the Makefile, and run make reboot:
 # cat >>Makefile <<EOT
 reboot: load reboot.o unix.a byte.a
      ./load reboot unix.a byte.a -static
 reboot.o: compile reboot.c reboot_system.h
      ./compile reboot.c
 EOT
 # make reboot

This gives you a reboot program, and with a minor change a halt program.

Regards, Gerrit.

[-- Attachment #2: reboot.c --]
[-- Type: text/plain, Size: 643 bytes --]

#include <unistd.h>
#include "reboot_system.h"
#include "strerr.h"

#ifndef RB_AUTOBOOT
#error "RB_AUTOBOOT undefined"
#endif

unsigned int doreboot =1;  /* set to 0 for halt */
int r =0;

int main(int argc, char **argv) {
  sync();
  if (doreboot)
    r =reboot_system(RB_AUTOBOOT);
  else {
#ifdef RB_POWER_OFF
    r =reboot_system(RB_POWER_OFF);
    if (r) strerr_die2sys(100, *argv, ": fatal: ");
#endif
#ifdef RB_HALT_SYSTEM
    r =reboot_system(RB_HALT_SYSTEM);
#else
#ifdef RB_HALT
    r =reboot_system(RB_HALT);
#else
    r =reboot_system(RB_AUTOBOOT);
#endif
#endif
  }
  if (r) strerr_die2sys(100, *argv, ": fatal: ");
  _exit(0);
}

Re: runit-1.0.0 release

[Alejandro Mery]

> I still have the sysvinit package on my systems, and use some of its
> tools.  It's very difficult to remove the 'essential' package sysvinit
> from a Debian system, even if runit is used as init scheme, because
> other essential packages depend on sysvinit directly (e.g. dpkg).

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 missing tools from daemontools like fghack (damn nullmailer) and to finily trace why runit-3 waits for ever the active ssh sessions to happyly say 'i have pool of usable isos 100% free of ancient software' (ifconfig, makedev, sysvinit, etc.)

best regards and thanks a lot,
Alejandro Mery

nullmailer & fghack? (was Re: runit-1.0.0 release)

[Charlie Brady]

On Thu, 12 Feb 2004, Alejandro Mery wrote:

> i'm just waiting for the last basic tools of sysvinit, for some missing
> tools from daemontools like fghack (damn nullmailer) ...

What's your problem with nullmailer? Bruce says it works so:

#! /bin/sh
exec setuidgid nullmail nullmailer-send 2>&1

--
Charlie

Re: nullmailer & fghack? (was Re: runit-1.0.0 release)

[Alejandro Mery]

On Thu, Feb 12, 2004 at 09:13:32PM -0500, Charlie Brady wrote:
> 
> On Thu, 12 Feb 2004, Alejandro Mery wrote:
> 
> > i'm just waiting for the last basic tools of sysvinit, for some missing
> > tools from daemontools like fghack (damn nullmailer) ...
> 
> What's your problem with nullmailer? Bruce says it works so:
> 
> #! /bin/sh
> exec setuidgid nullmail nullmailer-send 2>&1

uhm? mine goes to 'background' itself

using *your* script... 
# runsvctrl u nullmailer
# ps aux | grep nullmailer | head -n 10
root      1318  0.1  0.0  1276  276 ?        S    23:24   0:00 runsv nullmailer
nullmail  1322  0.0  0.1  2276  904 ?        S    23:24   0:00 nullmailer-send
nullmail  1324  0.0  0.1  2276  904 ?        S    23:24   0:00 nullmailer-send
nullmail  1326  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1328  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1332  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1334  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1336  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1343  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
nullmail  1345  0.0  0.1  2276  904 ?        S    23:25   0:00 nullmailer-send
# runsvctrl d nullmailer
# killall nullmailer-send

nullmailer-1.00RC7.tar.gz

i have search the source to patch it, but the only fork i found is to actually do the send. i'll have to take the time to strace it.
but if you get the author to fix it, *much* better.

Alejandro Mery

Re: nullmailer & fghack? (was Re: runit-1.0.0 release)

[Charlie Brady]

On Thu, 12 Feb 2004, Alejandro Mery wrote:

> On Thu, Feb 12, 2004 at 09:13:32PM -0500, Charlie Brady wrote:
> > 
> > What's your problem with nullmailer? Bruce says it works so:
> > 
> > #! /bin/sh
> > exec setuidgid nullmail nullmailer-send 2>&1
> 
> uhm? mine goes to 'background' itself
> 
> using *your* script... 

Not mine.

> i have search the source to patch it, but the only fork i found is to
> actually do the send. i'll have to take the time to strace it. but if
> you get the author to fix it, *much* better.

If *I* could get him to fix it? How about you report your problem? Address 
is, I believe, bgware@lists.untroubled.org.

---
Charlie

Re: nullmailer & fghack? (was Re: runit-1.0.0 release)

[Alejandro Mery]

Charlie Brady wrote:

>On Thu, 12 Feb 2004, Alejandro Mery wrote:
>
>  
>
>>On Thu, Feb 12, 2004 at 09:13:32PM -0500, Charlie Brady wrote:
>>    
>>
>>>What's your problem with nullmailer? Bruce says it works so:
>>>
>>>#! /bin/sh
>>>exec setuidgid nullmail nullmailer-send 2>&1
>>>      
>>>
>>uhm? mine goes to 'background' itself
>>
>>using *your* script... 
>>    
>>
>
>Not mine.
>  
>
i meaned, not something different that what you pasted here :\

>>i have search the source to patch it, but the only fork i found is to
>>actually do the send. i'll have to take the time to strace it. but if
>>you get the author to fix it, *much* better.
>>    
>>
>
>If *I* could get him to fix it? How about you report your problem? Address 
>is, I believe, bgware@lists.untroubled.org.
>
now, knowing that this is not the author's desired behavior of course
i'll bother him :-) thanks for saving me a the search for his address.

thanks again,
Alejandro Mery

Re: runit-1.0.0 release

[Gerrit Pape]

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.

> 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.

> 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.

Without a sshd/log service, the behavior should change, but you lose the
guarantee for your log.

Regards, Gerrit.

Re: runit-1.0.0 release

[Alejandro Mery]

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

Re: runit-1.0.0 release

[Gerrit Pape]

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.

Re: runit-1.0.0 release

[Stefan Karrmann]

Gerrit Pape (Thu, Feb 19, 2004 at 04:15:23PM +0000):
> 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.
> 
> > 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?

AFAIR, it opens a bunch of pipes, spawns the real demon and exits if ALL
pipes are closed in the demon. This happens normally on its death.
fghack might pass signals to the demon.

> > 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.

Try svwaitdown -xk -t450 /service/*/log

You may loose some log messages from slow grandchild demons.

Sincerly,
-- 
Stefan

runit-1.0.1 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Hi, runit version 1.0.1 is released and available through

 http://smarden.org/runit/

This release fixes a minor bug in the runsv program, and the service
logging daemon svlogd now converts TAI timestamps to UTC.  Basic testing
of the runit programs has been added to the end of the package build
process.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

runit-1.0.2 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

Hi, runit version 1.0.2 is released and available through

 http://smarden.org/runit/

The runsv program has been fixed to properly follow the documentation
when told to take a service down and exit, and now is capable of sending
the quit signal to a service; the runsvctrl has been adapted
accordingly.  A bug in svlogd handling its config file has been fixed,
and the documentation enhanced.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

runit-1.0.3 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi, runit version 1.0.3 is released and available through

 http://smarden.org/runit/

The runit program has been extended slightly: if stage 1 crashes or exits
100, stage 2 will be skipped; if stage 2 crashes or exits 111, it will be
restarted.  The chpst program provides a new option -/ to change the root
directory, and the collection of run scripts has been updated with various
contributions.

Regards, Gerrit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

runit-1.0.4 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Hi, runit version 1.0.4 is released and available through

 http://smarden.org/runit/

This release fixes a rarely seen race condition in the runsvdir program,
improves its handling of a special error case, and does some code cleanup.
The documentation and example macosx's startupitem for runit have been
updated slightly.

Regards, Gerrit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

runit-1.0.5 release

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Hi, runit version 1.0.5 is released and available through

 http://smarden.org/runit/

This release fixes some bugs in the svlogd service logging daemon, adds the
optional option -P to the runsvdir program to run the runsv processes in a
new session and process group, and cleans up some documentation.

Regards, Gerrit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]