|
Message-ID: <20120610132246.GF163@brightrain.aerifal.cx> Date: Sun, 10 Jun 2012 09:22:46 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Vision for new platform On Sun, Jun 10, 2012 at 02:53:49PM +0200, Daniel Cegiełka wrote: > 2012/6/10 Christian Neukirchen <chneukirchen@...il.com>: > > Rich Felker <dalias@...ifal.cx> writes: > > > >> A much better approach for systems that need automatic > >> stopping and starting of daemons would be to have a tiny > >> daemon-supervisor process to handle it; small systems with a very > >> "hands-on" admin not wanting to automate this could then skip the > >> supervisor daemon and start/stop manually. > > > > This is exactly what daemontools and variants do, with minimal code: > > http://cr.yp.to/daemontools.html > > http://offog.org/code/freedt.html > > > Chapter 4.1.1 Introducing procer: > http://mongrel2.org/static/book-finalch5.html Judging from its criticisms of daemontools, I suspect it might be just as broken as all the traditional script/pidfile-based approaches: There’s just one catch: all of them suck. There’s daemontools, which barely builds (if at all) and then assumes that daemons don’t fork. Stupid. Not stupid. Essential. If a daemon forks, there is no way to manage its lifetime generically. Period. Any attempt to do so is full of dangerous race conditions. You can manage the lifetimes for forking daemons in non-generic ways (like interfacing with them through a socket), but to make a robust system, every daemon you use must have a "do not fork" option. Thankfully, I think all of the mainstream ones already do, and if not, it's not something hard to patch in. As far as I know, systemd is pushing the same thing, so at least it's not an uphill battle to get this fixed in real-world software that's broken. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.