4 ms·

Runit is very similar in design to Daemontools, but it seems generally more featureful and better maintained. If you like one, chances are you'll like the other

by pjscott 14y ago

Runit is very similar in design to Daemontools, but it seems generally more featureful and better maintained. If you like one, chances are you'll like the other. (Also, daemontools' licensing is no longer an issue; it's been public domain since 2007.) I do take issue with your characterization of Upstart and Systemd as needlessly complex; almost all of that complexity is for their role as init.d replacements, and doesn't need to affect you if you just want to get a few programs running. Their big selling point, for me, is that one of them is usually the default and the config files are quite easy to write if you're not doing anything elaborate.

sigil 14y ago
As a diehard daemontools user this comment made me take another look at runit. Just to be clear, runit is one of several forks of daemontools. Another one is daemontools-encore [1]. There are a couple nice runit features that stock daemontools lacks. The ability to run each service in a separate process session with "runsvdir -P" is a big one. If your ./run file consists of a pipeline, bouncing the service with TERM will produce orphans otherwise. (I have some patches to daemontools-encore that do this on a per-service basis.) The svlogd program from runit also looks nicer than multilog. I've tried to like tai64, I really have, but I'd rather just have human AND machine readable timestamps from the get go. I like that service dependencies aren't statically declared in runit, but rather something you can block on in your ./run file. [1] http://untroubled.org/daemontools-encore/ http://untroubled.org/daemontools-encore/
- stock_toaster 14y ago
  runit also has man pages.
  - sigil 14y ago
    daemontools also has manpages, thanks to Garrit Pape, the author of runit ;) http://smarden.org/pape/djb/manpages/ http://smarden.org/pape/djb/manpages/ The manpages are installed by default in every system I use -- debian, ubuntu, MacPorts, and FreeBSD ports.
    - stock_toaster 14y ago
      Indeed. They are not part of the standard daemontools source though, which is why I thought it worth mentioning.

by pjscott 14y ago

sigil 14y ago

As a diehard daemontools user this comment made me take another look at runit. Just to be clear, runit is one of several forks of daemontools. Another one is daemontools-encore [1]. There are a couple nice runit features that stock daemontools lacks. The ability to run each service in a separate process session with "runsvdir -P" is a big one. If your ./run file consists of a pipeline, bouncing the service with TERM will produce orphans otherwise. (I have some patches to daemontools-encore that do this on a per-service basis.) The svlogd program from runit also looks nicer than multilog. I've tried to like tai64, I really have, but I'd rather just have human AND machine readable timestamps from the get go. I like that service dependencies aren't statically declared in runit, but rather something you can block on in your ./run file. [1] http://untroubled.org/daemontools-encore/ http://untroubled.org/daemontools-encore/

stock_toaster 14y ago
runit also has man pages.
- sigil 14y ago
  daemontools also has manpages, thanks to Garrit Pape, the author of runit ;) http://smarden.org/pape/djb/manpages/ http://smarden.org/pape/djb/manpages/ The manpages are installed by default in every system I use -- debian, ubuntu, MacPorts, and FreeBSD ports.
  - stock_toaster 14y ago
    Indeed. They are not part of the standard daemontools source though, which is why I thought it worth mentioning.