Re: How does exec work with systemd?
Cam Hutchison:
> I've been using runit for some time, which is a clone of daemontools
runit is not a clone of daemontools. s6
(http://skarnet.org/software/s6/) is much like daemontools, with some
extensions. It has the s6-svscan, s6-svscanctl, s6-supervise, s6-svc,
s6-svok, s6-svstat, s6-tai64nlocal, ... and so forth commands and a
superset of the service directory mechanism. daemontools-encore
(http://untroubled.org/daemontools-encore/) is much like daemontools,
with some extensions. It has the daemontools commands with their
daemontools names. And the service directory mechanism is much the
same, with a couple of extensions including an extended service state
model. Parts of nosh
(http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html)
have the same commands and interfaces as daemontools, for
compatibility. Again, there are svscan, svc, svok, svstat, tai64n,
tai64nlocal, and so forth. And again the mechanism is a superset of
the daemontools service directory one.
However, runit (http://smarden.org/runit/) is not as similar to
daemontools as any of those. Neither is perp
(http://b0llix.net/perp/). The command sets are quite different.
Instead of "svc", for example, there are "perpctl" and "sv" with
rather different option structures. Similarly, "chpst" and "runtool"
differ in usage from the daemontools commands for doing the same
things. The structure of the service directory mechanisms, in
particular (but not solely) the unequal relationship between "log"
services and "main" services, is also different.
Compared to other service management systems, there is a definite set
of family characteristics that all of these share. The filesystem is
the service control/status API, with much of that API common to all.
The service management system does the "daemonization", with daemons
that fork-then-exit-parent very strongly discouraged. Helper commands
prepare process state and do chain loading. "run"/"rc.main" is the
service program. Standard output/error go to a logging daemon. Log
daemons are services, too. But to describe any of them, except
perhaps daemontools-encore and s6 (which still does a disservice to
both), as clones is wrong and misleading. All of them, including even
daemontools-encore (which is the closest to being a clone),
incorporate design decisions that differentiate them from daemontools.
runit, nosh, and s6 provide programs explicitly designed to be process
#1 and do system management in addition to service management.
daemontools-encore and nosh have the aforementioned extended state
model in the control/status API. runit and perp have stronger
coupling between "log" and "main" services. runit provides workalikes
for runlevels. nosh provides workalikes for targets and service
start/stop dependencies. perp, nosh, and runit provide for base
directories other than /service/ . nosh can import (some) systemd
unit files. s6 has event FIFOs. perp's "rc.main" is passed
arguments. runit enables drop-in /etc/init.d shims. nosh has halt,
reboot, poweroff, systemctl, initctl, chkconfig, and service shim
commands. And so on.
Reply to: