daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts.
Also known as The Good Old Days. :-) I get a little annoyed with the way I keep running into new ways to start/stop/status processes on Linux systems. They used to be in rcX.d, then init.d, and now when I run one of those, it tells me to use something called service. Seems like I've seen a couple other methods over the years. No, I'm not going to seriously argue that throwing everything into rc.local was better, but....
On daemontools: it does a lot more than init.d scripts. It supervises processes and restarts them if stopped, provides easy logging and automated rollover of logs, and more. Combined with ucspi-tcp utilities like tcpserver, you can take a Perl script that simply reads from STDIN and writes to STDOUT, run it from daemontools with a few lines of shell script, and turn it into a network daemon with user- and IP-based security, multiple connections, logging of errors, and restart on die. I don't know how many of those other services provide that, but it's pretty handy.
I certainly would hate an application which came with its own service management scheme and which made me ferret out its own special way of telling me its status.
Agreed. Apache always annoyed me that way, by having its own apachectl. Most distributions now wrap that in an rc/init script so you don't have to know about it, but it made it more of a hassle to supervise with a system of your own choosing.
Aaron B.
Available for small or large Perl jobs; see my home node.
In reply to Re^4: RFC: an(other) UNIX daemon module implementation
by aaron_baugher
in thread RFC: an(other) UNIX daemon module implementation
by mantager
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |