Subject: runit VS daemontools - msg#00027

List: sysutils.supervision.general

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

Hi!

On Wed, Feb 18, 2004 at 06:30:09PM +0100, Clemens Fischer wrote:
> this might be valuable to a number of people. can you post the
> translation some place?

Comparation of runit's documentation VS daemontools's documentation. ;-)
(I've also added some noted from myself, not from documentation.)

This text may contain mistypo, bugs and even bad ideas. :)

Legend:
* just note
- runit don't have this daemontools feature
+ runit add this feature

* runit can be used as replacement for sysvinit and daemontools
but also can be used together with them
+ man and --help documentation
# maybe daemontools also has similar stdout/stderr behaviour, but I never
# seen it in daemontools before
* runsvdir's stdout by default going to first (?!) virtual console
* stdout of ./{run,finish} (if there is no ./log/run) and stdout of
./log/run is going to runsvdir's stdout
* stderr of ./run and ./finish and ./log/run going to runsvdir's title
# runsvdir VS svscanboot + svscan + readproctitle
+ runsvdir has functionality of svscanboot + svscan + readproctitle
which is very useful and safe against another one bash process in
memory (for pipe between svscan and readproctitle)
* runsvdir execute runsv (svscan execute supervise)
+ service will be stopped automatically if it disappear from /var/service/
directory (so there is no need for additional svc -dx command after
removing service)
# runsv VS supervise
+ support ./finish script which (if exists) will be executed after ./run
exits (./finish stdout also send to ./log/run if it exists)
+ current service status available in text format in files
./supervise/{stat,pid} (supervise-compatible binary status in
./supervise/status is also supported)
+ when terminating service if it has ./log/run then runsv will first
terminate ./run then close ./log/run's stdin then wait until ./log/run
exits - this make logs more reliable
+ both ./run and ./log/run served by single runsv process
# runsvctrl VS svc
+ able to send SIGUSR1 and SIGUSR2 to service
- don't able to send more than one command at once like `svc - dx`
* commands are readable plain text ("down" instead of "-d")
# runsvstat VS svok + svstat
* has functionality of svok (exit code) and svstat (print server status)
* can optionally show ./log/ statuses in addition to main service status
# chpst VS pgrphack + setuidgid + envuidgid + envdir + setlock + softlimit
* has functionality of pgrphack + setuidgid +envuidgid + envdir + setlock +
softlimit
+ allows set group different from user's main group
+ able to close STDIN/STDOUT/STDERR
- no way to define what to do (exit(0) or print error and exit(1)) in case if
it fail to open/close/lock lock-file
- no way to set soft limit to hard limit like softlimit do it (bug in docs?)
- no way to set separate memory limits (data/stack/locked/total) - they all
set to same value
- no way to set soft limits for RSS and CPU
# svlogd VS multilog
* executing external program as "processor" explained in documenation in
much more details, but it's unclear is it differ from multilog
+ log configurations moved from multilog's paramemters to /logdir/config
(file may not exists), it also support comments
+ may send data to syslog using UDP
+ a little extended patterns for selecting strings to log
+ able to add timestamp with microseconds(micro?) in sortable text format
(it's unclean from docs, but probably in GMT)
+ able to replace unprintable plus user-defined chars by one user-defined
+ it's possible to control maximum string length and size of read buffer
+ SIGHUP: reopen all logs and reread /logdir/config files
+ SIGALRM: force (non-empty) log rotation now
# utils only in daemontools:
- fghack
- tai64n
- tai64nlocal
# added service dependencies
+ svwaitup ( http://smarden.org/pape/djb/daemontools/noinit.html )
* should be executed from ./run before service daemon itself
+ able to wait until required services will be "up" for at least
(configurable) timeout seconds
- as author noted, this way isn't safe because race still possible;
IMHO Right Way to realize service dependencies is use some sort of
IPC between ./run and runsvdir so all ./run scripts will be able to
register is't provides or dependences in one daemon which guarantied
to be running (after runsvdir die system will be rebooted), and runsvdir
will be able to control service executing order and check is they alive;
btw, this race may be (?) worked around by stopping all services which
require this one from it's ./finish script.
# added safe shutdown for services at reboot/halt
+ svwaitdown
+ able to send down, kill, exit commands to services and wait
until they exits or timeout happens
# added runlevels support
+ runsvchdir
# added sysvinit replacement
+ runit-init: replaced /sbin/init; execute runit at system boot time
+ runit
+ simple /etc/inittab replacement by using 4 hardcoded script names
for initializing (/etc/runit/1), execute services including getties
(/etc/runit/2), prepare for reboot/halt (/etc/runit/3) and process
ctrl+alt+del (/etc/runit/ctrlaltdel)
+ restart /etc/runit/2 if it died (hmm.. looks like on my server it
going to reboot instead... is it my mistake or bug in runit?)
+ SIGINT: emulate ctrl+alt+del
+ SIGCONT: doing reboot/halt if executable file /etc/runit/stopit exists
(hmm, looks like it impossible to reboot while executing /etc/runit/1 -
for example if it executed /sbin/sulogin I'm unable to reboot/halt from
it...)
+ utmpset
* complement runit-init functionality (sysvinit add records to utmp/wtmp,
but runit-init doesn't) by adding 'logout' information to utmp/wtmp
(should be executed in ./finish script for getty-* services)
# new/changed files and directories:
/etc/runit/1
/etc/runit/2
/etc/runit/3
/etc/runit/reboot
define what should be done on shutdown: halt or reboot
/etc/runit/ctrlaltdel
script for processing ctrl+alt+del (able to block rebooting)
/etc/runit/stopit
allow or deny system reboot (for use in ctrlaltdel script, for example)
/var/service/
now - symlink, was directory /service/
/etc/runit/runsvdir/current/
symlink to current runlevel (really, to directory with services, "default"
for example)
/etc/runit/runsvdir/default/
directory with services for runlevel "default"
./finish
executed after ./run exits
./supervise/{stat,pid}
contain service status in text format
/logdir/config
contain svlogd paramemtes for this /logdir/

--
WBR, Alex.

Thread at a glance:

Previous Message by Date:

Re: reboot->wtmp

* Alex Efros: > I very like djb's phylosofy and soft, and also like runit's > features... but I also like to have selected lines from *ALL* logs > stored in separate file (like /var/log/everything/current) and also > shown at tty10 for monitoring purposes... there are a couple of other logging tools you could combine. the one that comes to my mind is the syslogtools package by tim goodwin. > P.S. I've compared daemontools vs runit (just line-by-line compare > documentation for similar utilites). If anybody want it, I can post > this comparation here (I think it will be nice to have webpage with > this information at runit's website - just to make more clear for > people what they need: daemontools or runit). But this will take > some time because I've wrote it in native language (russian) and I > should translate it to english before post. this might be valuable to a number of people. can you post the translation some place? clemens

Next Message by Date:

Re: runit-1.0.0 release

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.

Previous Message by Thread:

Next Message by Thread:

Re: runit VS daemontools

On Wed, Feb 18, 2004 at 10:48:02PM +0200, Alex Efros wrote: > On Wed, Feb 18, 2004 at 06:30:09PM +0100, Clemens Fischer wrote: > > this might be valuable to a number of people. can you post the > > translation some place? > > Comparation of runit's documentation VS daemontools's documentation. ;-) > (I've also added some noted from myself, not from documentation.) This is very nice, and nearly complete. Thanks a lot. > # runsvctrl VS svc > + able to send SIGUSR1 and SIGUSR2 to service > - don't able to send more than one command at once like `svc - dx` You can simply use # echo -n 'dx' >/var/service/<service>/supervise/control > # chpst VS pgrphack + setuidgid + envuidgid + envdir + setlock + softlimit > * has functionality of pgrphack + setuidgid +envuidgid + envdir + setlock + > softlimit > + allows set group different from user's main group > + able to close STDIN/STDOUT/STDERR > - no way to define what to do (exit(0) or print error and exit(1)) in case if > it fail to open/close/lock lock-file > - no way to set soft limit to hard limit like softlimit do it (bug in docs?) > - no way to set separate memory limits (data/stack/locked/total) - they all > set to same value > - no way to set soft limits for RSS and CPU You can run the chpst program as 'setlock' or 'softlimit' (or 'dsetlock', "dsoftlimit'), then it accepts the same options as the corresponding daemontools programs. Regards, Gerrit.