Comment by mrweasel | Hacker News Reader

Comment by mrweasel | Hacker News Reader

I still prefer Bernsteins daemon-tools. I first used them when I had to deploy qmail and now I use them to manage Python webapplications. The default logging option is a bit weird, but the simplicity is a real winner for me.

I don't like Upstart, I don't agree that it's "admirably simple to use", it needlessly complex. For what I do, I don't need or want to care about runlevels, I always want respawning and I don't like the syntax of the configuration.

systemd seems like a really complex solution to a very simple problem, but I never used it.

Supervisord while being well documented and popular again seems to complicate what I want to do. Again I dislike the configuration, I fail to see why a shell script isn't better.

Runit I never used, because why would I replace daemon-tools with, what was when I first read about it, just a daemon-tools clone, made by people who didn't like Bernsteins licensing. I guess it's what I would most likely go for, if daemon-tools where not available.

The rest I never heard of.

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.

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/

runit also has man pages.

daemontools also has manpages, thanks to Garrit Pape, the author of runit ;)

http://smarden.org/pape/djb/manpages/

The manpages are installed by default in every system I use -- debian, ubuntu, MacPorts, and FreeBSD ports.

Indeed. They are not part of the standard daemontools source though, which is why I thought it worth mentioning.

Daemontools has never let me down. It plays nicely with the OS in that I don't have to muck around with essential system daemons and init scripts, and it corrects all sorts of bad behavior. I run everything with it: python, java (including long-running servers), ruby, perl... Really a fantastic package.

You could easily have written the exact same thing about Upstart, Systemd, or Runit. :-)

I think it's a question of which tool you learn first. You learn one, it solves your problems and the rest does it differently, so they're "wrong" or difficult in your eyes.

accidental downvote (arrows are teeny on mobile!).

I agree with liking the simplicity of daemontools. I haved used it for a while, and it has served me well. I like that logging is split. I often run the log script as just a logger instance to get stdout to syslog.

Upstart is.... Not my favorite.

runit is nice. Like daemontools with manages and a few extra flags/features.

mongroup is dead simple and succinct. It might be your taste. https://github.com/jgallen23/mongroup

Reply on news.ycombinator.com