[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
