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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACF=bdvbdgvrzy0deuqwwf7bwbaj8_y8+f9pgmaadvw_ibu...@mail.gmail.com
