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.