The daemontools family | Hacker News Reader

The daemontools family

homepage.ntlworld.com.

65 pointsvezzy-fnord23 comments

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-...

[2] http://www.freshports.org/sysutils/daemontools-encore/

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.

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

There's also functionality in BusyBox, specifically the sv and associated tools:

http://busybox.net/downloads/BusyBox.html

More commentary here:

http://busybox.net/~vda/init_vs_runsv.html

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

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.

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.

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.

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.

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.

Maybe my needs just aren't that exotic? I'm currently using daemontools at work and so far I have a slightly unfortunate handful of bash scripts that repeat in different projects with minor variations.

I've also used launchd (OSX) for Serious Things That I Don't Want to Fail, and it was easy. One config file with a few details. Completely watertight abstraction, as far as I could tell.

launchd is an ad-hoc hell of its own, as I've written about here: https://news.ycombinator.com/item?id=9924879

Pretty much all of the new school init systems, loosely starting from 2004 onwards (Upstart, launchd, Solaris SMF, systemd) have glaring structural deficiencies in one way or another, from my observations.

Exactly. I just want to keep a couple of processes running without having to learn the DJB ecosystem. I also want them portable if we shift off CentOS to Ubuntu in the future or something.

I'd argue that the DJB ecosystem has an almost-zero learning curve if you have a decent grasp on your systems fundamentals. As long as you understand how process handling works, the administrivia of DJB's tools is dirt simple.

It also has the odd benefit of already being cross-platform, so even if you move whole systems distributions (e.g., from Debian GNU/Linux to FreeBSD), you can still use that same knowledge there too.

Edit: Note that simple does not imply easy. Daemontools, for example, does not provide a means for doing dependency handling, so you'll actually have to engineer around that by writing a script to handle it. Same goes for bouncing things that go off the rails. Same goes for pretty much anything that does not fall strictly under the purview of starting a process and restarting it if it crashes.

I just want to keep a couple of processes running without having to learn the DJB ecosystem

Try this 150-line C program, it's good enough for that one simple task: https://github.com/urbit/babysit/blob/master/babysit.c

Simplicity by leaving everything switched off by default, but still sendmail and BIND the default MTA and DNS server. I know OpenSMTPd has come in now, but I still never found out why djb's tools weren't first class citizens and default.

> I wish there was a DJB Linux/Unix.

One is being developed by DJB and some colleagues and students, called Ethos. Among other interesting features (like their own PKI called SayI), its principal network transport will be MinimaLT, which they are also actively developing. They're also working on a minimaltd port for other operating systems.

I don't know of a timetable but development is active and they keep hitting milestones.

  http://www.ethos-os.org
  http://www.ethos-os.org/~solworth/minimalt-20131031.pdf

Void Linux uses runit, which is very similar to daemontools as its init system.

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

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.

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.

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.

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

Reply on news.ycombinator.com