3 ms·

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

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.

vezzy-fnord 11y ago
launchd is an ad-hoc hell of its own, as I've written about here: https://news.ycombinator.com/item?id=9924879 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.
blackbeard 11y ago
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 11y ago
  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.
- vezzy-fnord 11y ago
  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 https://github.com/urbit/babysit/blob/master/babysit.c

vezzy-fnord 11y ago

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

blackbeard 11y ago

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 11y ago
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.
vezzy-fnord 11y ago
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 https://github.com/urbit/babysit/blob/master/babysit.c