while true; do
tar czf - data | ssh backup tar xzf -
> Attempts to package this for Debian Linux have not got off the ground...
I've got a PPA for daemontools-encore here , 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 .
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.
More commentary here:
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.
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.
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.
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.
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.
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.
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.
Try this 150-line C program, it's good enough for that one simple task: https://github.com/urbit/babysit/blob/master/babysit.c