7 ms·

The daemontools family

65 points by vezzy-fnord 11y ago

aidenn0 11y ago
nosh is one I hadn't heard of that looks really interesting. I use daemontools for service monitoring, but nosh is the first dt derivative I've seriously considered as a sysvinit replacement.
caractacus 11y ago
What surprises me more than anything about this is that ntlworld.com still exists and still resolves.
- richardwhiuk 11y ago
  Probably plenty of ntlworld customers who haven't changed providers (and are now Virgin Media customers). I think I still had a working email address with them.
  - jwdunne 11y ago
    This is true. I have seen many working ntlworld.com emails. NTL, when my parents switched from a 56k modem. Good memories. I remember having an argument with my parents about NTL's search engine. They tried saying Google was screwing their computer up because they used NTL search. I may have set Google as their homepage. This may have been deliberate.
  - nly 11y ago
    My parents still use their ntlworld email addresses. Virgin Media moved all their email infrastructure to Google some time ago, but are now in the process of moving it back in-house.
_ak 11y ago
There's also minit: http://www.fefe.de/minit/ http://www.fefe.de/minit/
sigil 11y ago
One nice daemontools-encore feature not mentioned here: support for multiprocess services. By default, services run in their own process group, and `svc -t` and friends will cleanly signal the entire process group. Classic daemontools and all the derivatives I'm aware of will spin off orphans when you send TERM to a multiprocess service (eg, anything that involves a shell pipeline) like #!/bin/sh while true; do tar czf - data | ssh backup tar xzf - sleep 60 done If you've ever admin'ed a multiprocess service, you know how annoying the orphan problem can be. > Attempts to package this for Debian Linux have not got off the ground... I've got a PPA for daemontools-encore here [1], if you're interested. Be aware that the package itself is named daemontools so that it functions as a drop-in replacement for classic daemontools, and plays nicely with the daemontools-run package. > and it is not in the BSD ports/packages trees... This info is out of date, daemontools-encore 1.10 is in the FreeBSD ports tree [2]. [1] https://launchpad.net/~alangrow/+archive/ubuntu/daemontools-encore https://launchpad.net/~alangrow/+archive/ubuntu/daemontools-... [2] http://www.freshports.org/sysutils/daemontools-encore/ http://www.freshports.org/sysutils/daemontools-encore/
- rbirnie 11y ago
  Multiprocess support works in general pretty well but isn't perfect. Daemontools-encore still has issues with KILL signals, with HTTPD and MPMs a KILL signal will kill the master but workers often go to init and never stop.
  - sigil 11y ago
    What HTTPD are you running? If you're running one that does its own child process management (like nginx or apache), you should explicitly disable process group isolation via a ./no-setsid file. http://untroubled.org/daemontools-encore/supervise.8.html http://untroubled.org/daemontools-encore/supervise.8.html
nailer 11y ago
I wish there was a DJB Linux/Unix. DJB has clear ideas about service management, ideas about to implement those services, and licensing, but they often clash with existing widespread tools or practices. That's not a problem, but the best place for them would be their own Unix variant.
- sigil 11y ago
  I've always thought OpenBSD and daemontools would be a great fit. Among other things, OpenBSD and djb share a fanatical devotion to security through simplicity. As the systemd apocalypse approaches, those of us who strongly disagree with that maximalist approach will start looking around for alternatives. Adopting daemontools (or a derivative) into the base system, and phasing out the old SysV init scripts, would make a distro suddenly very attractive.
  - blackbeard 11y ago
    I have found that systemd whilst large is actually spot on for managing services particularly from say ansible. Just drop a service file and the binary on disk and start the service. No external supervisor process, no funny acres of bash to HUP and KILL stuff. Just works. It solves the old problem of "so how the hell do I restart this network interface on distro X" as well. I'm a pragmatist and it does solve a lot of core configuration issues with Linux.
    - vezzy-fnord 11y ago
      Well, there's something to be said for daemontools which insists you set up a properly managed service namespace as opposed to going towards the convenient but limited route of the quick fix. I still don't see how "svc -u" is more complicated than "systemctl start", though. That said, I would definitely not characterize systemd as "just works". Besides the issues that come with its intertwining system state, service state, process management, process supervision, configuration parsing and so on all in one critical process, the unit file mechanism is significantly less expressive than the chain loading mechanism (which really shines when used with a small dedicated lexer for run scripts like execline). You are limited within the bounds of the INI key pairs and you have no way to compose them, because they're just fixed entries in a hash table that systemd sets up at build time to look up. The dependency mechanism is a quagmire of its own, with it mixing up semantics between ordering and dependence while limiting the service relationship types to whatever the systemd toolkit gives you. It introduces the problem of dependency loops which barely give you any debugging context when they occur, and it requires that systemd maintain complicated internal job and transaction consistency checking for a dependency system which will fundamentally always remain incomplete, because dependencies with respect to processes work entirely different compared to dependencies in libraries where you have fixed expectations of public symbols, relocated and resolved by the dynamic loader. It feels like systemd, in the part where it's best at - service management, isn't ambitious enough. Instead it has decided to be a sprawling middleware doing 100 things and none of them completely, in an attempt to be a standard userland you just theoretically plug in between GNU and Linux and get a distro. In practice, the integration work required to maintain a systemd-compliant runtime and keep up with the rapid chaotic pace of development is not any less difficult than maintaining poorly written SysV initscripts.
zdw 11y ago
There's also functionality in BusyBox, specifically the sv and associated tools: http://busybox.net/downloads/BusyBox.html http://busybox.net/downloads/BusyBox.html More commentary here: http://busybox.net/~vda/init_vs_runsv.html http://busybox.net/~vda/init_vs_runsv.html
rconti 11y ago
Let me guess, the documentation is in hex for no apparent reason.

65 points by vezzy-fnord 11y ago

nosh is one I hadn't heard of that looks really interesting. I use daemontools for service monitoring, but nosh is the first dt derivative I've seriously considered as a sysvinit replacement.

caractacus 11y ago

What surprises me more than anything about this is that ntlworld.com still exists and still resolves.

richardwhiuk 11y ago
Probably plenty of ntlworld customers who haven't changed providers (and are now Virgin Media customers). I think I still had a working email address with them.
- jwdunne 11y ago
  This is true. I have seen many working ntlworld.com emails. NTL, when my parents switched from a 56k modem. Good memories. I remember having an argument with my parents about NTL's search engine. They tried saying Google was screwing their computer up because they used NTL search. I may have set Google as their homepage. This may have been deliberate.
- nly 11y ago
  My parents still use their ntlworld email addresses. Virgin Media moved all their email infrastructure to Google some time ago, but are now in the process of moving it back in-house.

_ak 11y ago

There's also minit: http://www.fefe.de/minit/ http://www.fefe.de/minit/

sigil 11y ago

One nice daemontools-encore feature not mentioned here: support for multiprocess services. By default, services run in their own process group, and `svc -t` and friends will cleanly signal the entire process group. Classic daemontools and all the derivatives I'm aware of will spin off orphans when you send TERM to a multiprocess service (eg, anything that involves a shell pipeline) like #!/bin/sh while true; do tar czf - data | ssh backup tar xzf - sleep 60 done If you've ever admin'ed a multiprocess service, you know how annoying the orphan problem can be. > Attempts to package this for Debian Linux have not got off the ground... I've got a PPA for daemontools-encore here [1], if you're interested. Be aware that the package itself is named daemontools so that it functions as a drop-in replacement for classic daemontools, and plays nicely with the daemontools-run package. > and it is not in the BSD ports/packages trees... This info is out of date, daemontools-encore 1.10 is in the FreeBSD ports tree [2]. [1] https://launchpad.net/~alangrow/+archive/ubuntu/daemontools-encore https://launchpad.net/~alangrow/+archive/ubuntu/daemontools-... [2] http://www.freshports.org/sysutils/daemontools-encore/ http://www.freshports.org/sysutils/daemontools-encore/

rbirnie 11y ago
Multiprocess support works in general pretty well but isn't perfect. Daemontools-encore still has issues with KILL signals, with HTTPD and MPMs a KILL signal will kill the master but workers often go to init and never stop.
- sigil 11y ago
  What HTTPD are you running? If you're running one that does its own child process management (like nginx or apache), you should explicitly disable process group isolation via a ./no-setsid file. http://untroubled.org/daemontools-encore/supervise.8.html http://untroubled.org/daemontools-encore/supervise.8.html

nailer 11y ago

I wish there was a DJB Linux/Unix. DJB has clear ideas about service management, ideas about to implement those services, and licensing, but they often clash with existing widespread tools or practices. That's not a problem, but the best place for them would be their own Unix variant.

sigil 11y ago
I've always thought OpenBSD and daemontools would be a great fit. Among other things, OpenBSD and djb share a fanatical devotion to security through simplicity. As the systemd apocalypse approaches, those of us who strongly disagree with that maximalist approach will start looking around for alternatives. Adopting daemontools (or a derivative) into the base system, and phasing out the old SysV init scripts, would make a distro suddenly very attractive.
- blackbeard 11y ago
  I have found that systemd whilst large is actually spot on for managing services particularly from say ansible. Just drop a service file and the binary on disk and start the service. No external supervisor process, no funny acres of bash to HUP and KILL stuff. Just works. It solves the old problem of "so how the hell do I restart this network interface on distro X" as well. I'm a pragmatist and it does solve a lot of core configuration issues with Linux.
  - vezzy-fnord 11y ago
    Well, there's something to be said for daemontools which insists you set up a properly managed service namespace as opposed to going towards the convenient but limited route of the quick fix. I still don't see how "svc -u" is more complicated than "systemctl start", though. That said, I would definitely not characterize systemd as "just works". Besides the issues that come with its intertwining system state, service state, process management, process supervision, configuration parsing and so on all in one critical process, the unit file mechanism is significantly less expressive than the chain loading mechanism (which really shines when used with a small dedicated lexer for run scripts like execline). You are limited within the bounds of the INI key pairs and you have no way to compose them, because they're just fixed entries in a hash table that systemd sets up at build time to look up. The dependency mechanism is a quagmire of its own, with it mixing up semantics between ordering and dependence while limiting the service relationship types to whatever the systemd toolkit gives you. It introduces the problem of dependency loops which barely give you any debugging context when they occur, and it requires that systemd maintain complicated internal job and transaction consistency checking for a dependency system which will fundamentally always remain incomplete, because dependencies with respect to processes work entirely different compared to dependencies in libraries where you have fixed expectations of public symbols, relocated and resolved by the dynamic loader. It feels like systemd, in the part where it's best at - service management, isn't ambitious enough. Instead it has decided to be a sprawling middleware doing 100 things and none of them completely, in an attempt to be a standard userland you just theoretically plug in between GNU and Linux and get a distro. In practice, the integration work required to maintain a systemd-compliant runtime and keep up with the rapid chaotic pace of development is not any less difficult than maintaining poorly written SysV initscripts.

zdw 11y ago

There's also functionality in BusyBox, specifically the sv and associated tools: http://busybox.net/downloads/BusyBox.html http://busybox.net/downloads/BusyBox.html More commentary here: http://busybox.net/~vda/init_vs_runsv.html http://busybox.net/~vda/init_vs_runsv.html

rconti 11y ago

Let me guess, the documentation is in hex for no apparent reason.