[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120610225226.137363d0@sibserver.ru>
Date: Sun, 10 Jun 2012 22:52:26 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
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 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.
Otherwise you can't trust the daemon that is running from init scripts.
(I'm a bit paranoid here)
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.
