
The daemontools family - vezzy-fnord
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html
======
sigil
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-...](https://launchpad.net/~alangrow/+archive/ubuntu/daemontools-
encore)

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

~~~
rbirnie
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
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)

------
zdw
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)

------
_ak
There's also minit: [http://www.fefe.de/minit/](http://www.fefe.de/minit/)

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

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

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

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

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

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

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

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

