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.