[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2012 17:17:47 +0200
From: Daniel Cegiełka <daniel.cegielka@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
2012/6/10 orc <orc@...server.ru>:
> 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)
I think a lot depends on how we want to use our system. If its user
desktop, a solution such as systemd are very comfortable. If we want
to have a 'critical' system (RTOS/security) then it's better to keep
independent init as simple process.
Orc, I agree with your opinion...
Daniel
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.
