Have a look at this excellent comparison for supervisor / init tools: http://skarnet.org/software/s6/why.html
S6 is the bees' knees On 28 March 2015 at 01:32, Steve Litt <[email protected]> wrote: > Hi all, > > I'm managing more and more of my daemons with daemontools. This is > currently happening on my sysvinit-initted Wheezy, but I think I'll do > it forever. By the way, anything good I say about daemontools goes > even more so for Bruce Gunter's daemontools-encore. > > I could have managed my daemons with sysvinit, using the respawn, and a > lot of people ask me "what's the point of the extra software > (daemontools) when it's already doable from your init system?" > > Here's why: > > * Daemontools has a rich set of tools to start, stop, and restart your > daemons. > * Daemontools has built-in logging that captures everything from the > daemon's stdout (stderr too if you want). > * Daemontools' svstat command gives you the daemon's PID: No guessing, > no .pid files, no parsing ps ax. > * Daemontools is ultra-reliable. > * Daemontools is dead bang simple, constructed purely from Unix > constructs. It's completely understandable. > * Daemontools can be made to run at the end of a boot, thereby removing > complexity from the init itself. > * If you can devise a test to show that a required service is running > correctly, you can implement service dependencies reliably with > Daemontools. > * Daemontools can take any old shellscript or Python/Perl/Ruby/Lua > program you write and turn it into an always starts, reliably managed > daemon, with logging. Daemontools is the easy way to deploy DIY > daemons. > * A deep understanding of daemontools, which is not hard to achieve, > gives you a big head start on understanding actual init programs. > * Daemontools gives you much better ways to declare that daemons run or > don't run than lame, number-in-comments symlinks to five function > init scripts. > * Daemontools init scripts are pretty much all the same, are short and > easy to understand. Contrast this to sysvinit, systemd, OpenRC or > Upstart. > > The following is my daemontools run script for ntpd. Note that it > enforces a dependency that the network be up before it starts: > > ================================================== > #!/bin/sh > > ######## DON'T START ntpd UNTIL THE NETWORK'S UP ####### > pingaddr=8.8.8.8 > #pingaddr=8.8.8.86 # for testing unpingable IP address > echo "Starting Litts ntpd daemon" > echo "Litts ntpd daemon checking network" > if ! ping -q -c1 $pingaddr > /dev/null; then > echo failed ping test on $pingaddr > sleep 3 > echo "Bailing til next time" > exit 1 > fi > > ####### RUN THE DAEMON ####### > echo ping test succeeded, starting ntpd > exec 2>&1 > echo About to start ntpd > exec /usr/sbin/ntpd -d -s > > ================================================== > > For the guy who has memorized all of systemd's init keywords, this is a > little bit more complicated than the equivalent systemd unit file. Foor > the guy who hasn't memorized systemd's unit file keywords, this is much > easier and more intuitive. Anyone with a bit of Unix knowledge and the > understanding that a daemontools run script that terminates gets > restarted by supervise in 1 to 5 seconds instantly understands what > this script is doing, and can write it from his/her knowledge. > > In my opinion, no matter what init system you're running, daemontools > or daemontools-encore is a great addition to make your system more > understandable and maintainable. > > SteveT > > Steve Litt * http://www.troubleshooters.com/ > Troubleshooting Training * Human Performance > > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
