Re: Re: Vision for new platform

["Daniel Cegiełka" <daniel.cegielka@gmail.com>]

2012/6/10 orc <orc@sibserver.ru>:
> On Sun, 10 Jun 2012 09:22:46 -0400
> Rich Felker <dalias@aerifal.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