[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2012 11:13:11 -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 10:52:26PM +0800, orc wrote:
> On Sun, 10 Jun 2012 09:22:46 -0400
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > 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.
>
> If we need no starting and stopping, than this can be already
> implemented in init scripts. Only a simple program-wrapper that
> forcibly daemonizes that daemons with "do not fork" option needed.
> Optionally it can report a pid after fork() before execvp().
I don't think you're getting the issue at hand. Suppose you want to be
able to automatically bring down a particular daemon -- perhaps to
restart it with completely new configuration or to switch to a new
version of it. This could happen as part of an automated upgrade
process or under manual admin control.
Traditional init scripts DO NOT solve this problem. They are extremely
buggy, ranging from doing things as stupid as killing any instance of
the daemon (even one run by a user as opposed to by root with a
separate config file and running on a separate port) to killing
unrelated processes (by scanning /proc or reading a pid file, then
subsequently killing the pid which might not belong to a different
process).
> I just think that init subsystem must be as simple as possible,
> without additional machinery like automatic starting and stopping and
> watching for daemons status (but optionally it can be developed, of
> course, there is no limits at all). If daemon segfaults for example,
> than this is a daemon's failure that *must* be fixed in daemon, not in
> init subsystem. Daemon restarts can result in data loss.
I agree that the problem of daemons crashing or otherwise exiting
unexpectedly is one that should be fixed in the daemons. Unfortunately
that's much harder than it sounds. A large portion of the daemons in
modern use are using "xmalloc" type wrappers that abort
unconditionally on malloc failure, either directly or by virtue of
using atrociously-bad libraries like glib that abort without the
caller's consent.
If daemons really didn't exit unexpectedly, the only race condition in
pid-based approaches to lifetime management would be races between
multiple scripted administrative actions (e.g. 2 admins trying to down
the daemon at the same time) which could be fixed by locking at the
script level.
Still, I think the best approach if you want to be able to manage
scripted start/stop of daemons is to insist that they not fork and
have their direct parent be responsible. BTW, systemd cheats in this
regard: it's ALWAYS the direct parent of daemons that forked, because
orphaned processes get re-parented to PID #1.
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.
