Minimal init
 

> Not rocket science about ipc only a loop and two signal to catch:
> - get SIGING: respawn systemd
> - get SIGUSR2: spawn a sulogin shell
> - check if systemd child die, respawn it if needed (rate limited)
>
> All the funky stuff is done by a child of init.

Hmm.... If you want to support forking daemons, you'll also want
a protocol to signal the child that a monitored process has exited,
won't you?

-- Juliusz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bowqgwmd.fsf_-_@trurl.pps.jussieu.fr">http://lists.debian.org/87bowqgwmd.fsf_-_@trurl.pps.jussieu.fr

Minimal init
 

On Tue, Jul 19, 2011 at 4:42 PM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>> Not rocket science about ipc only a loop and two signal to catch:
>> - get SIGING: respawn systemd
>> - get SIGUSR2: spawn a sulogin shell
>> - check if systemd child die, respawn it if needed (rate limited)
>>
>> All the funky stuff is done by a child of init.
>
> Hmm.... If you want to support forking daemons, you'll also want
> a protocol to signal the child that a monitored process has exited,
> won't you?

No, it is the same problem with systemV init of systemd.

Forking daemon are reparented to init and we do not know if exit is
genuine or not.

It seems this problem (double fork) is the basement of using cgroup
under systemd ;)

Bastien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAbAd3ZxghLm+UCb-zWXA6ZZdp8btJ=4x4ep66omp1SK=w@mail.gmail.com">http ://lists.debian.org/CAE2SPAbAd3ZxghLm+UCb-zWXA6ZZdp8btJ=4x4ep66omp1SK=w@mail.gmail.com

Minimal init
 

Bastien ROUCARIES writes ("Re: Minimal init [was: A few observations about systemd]"):
> Forking daemon are reparented to init and we do not know if exit is
> genuine or not.

Right.

> It seems this problem (double fork) is the basement of using cgroup
> under systemd ;)

I think messing around with cgroups is a ridiculous way to solve this
problem. The right answer is simply to change the daemons to give
them an option which causes them not to fork. Then you can just have
a single supervision daemon which reaps (and restarts, if desired).

I haven't done a survey of the available init replacements but this is
not a new concept and I hope that most of them implement it as a
possibility.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20005.41054.544675.800675@chiark.greenend.org.uk"> http://lists.debian.org/20005.41054.544675.800675@chiark.greenend.org.uk

Minimal init
 

Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit :
> I think messing around with cgroups is a ridiculous way to solve this
> problem. The right answer is simply to change the daemons to give
> them an option which causes them not to fork. Then you can just have
> a single supervision daemon which reaps (and restarts, if desired).

But the daemon may want to start external tools, which may double fork.
It's a good thing to be able to catch them too.

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110719153904.GP8064@const.famille.thibault.fr">h ttp://lists.debian.org/20110719153904.GP8064@const.famille.thibault.fr

Minimal init
 

On Tue, Jul 19, 2011 at 5:18 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Bastien ROUCARIES writes ("Re: Minimal init [was: A few observations about systemd]"):
>> Forking daemon are reparented to init and we do not know if exit is
>> genuine or not.
>
> Right.
>
>> It seems this problem (double fork) is the basement of using cgroup
>> under systemd ;)
>
> I think messing around with cgroups is a ridiculous way to solve this
> problem. *The right answer is simply to change the daemons to give
> them an option which causes them not to fork. *Then you can just have
> a single supervision daemon which reaps (and restarts, if desired).

You could not forbid cgi bin to not fork.

>
> I haven't done a survey of the available init replacements but this is
> not a new concept and I hope that most of them implement it as a
> possibility.

The main problem is they are two concepts of init:
1. immortal child reaper what should not go mad (even malloc should not fail).
2. superdaemon that track/run other daemon and run login

The two are orthogonal. The main problem of actual init (even systemd)
is that they merge the two concept.

> Ian.
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAYcuFXRd9tgS7-D9PL5OgNHdAaEQhfES4VCjgyB8vUGog@mail.gmail.com">ht tp://lists.debian.org/CAE2SPAYcuFXRd9tgS7-D9PL5OgNHdAaEQhfES4VCjgyB8vUGog@mail.gmail.com

Minimal init
 

Samuel Thibault writes ("Re: Minimal init [was: A few observations about systemd]"):
> Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit :
> > I think messing around with cgroups is a ridiculous way to solve this
> > problem. The right answer is simply to change the daemons to give
> > them an option which causes them not to fork. Then you can just have
> > a single supervision daemon which reaps (and restarts, if desired).
>
> But the daemon may want to start external tools, which may double fork.
> It's a good thing to be able to catch them too.

No, I don't think so. If these external tools double fork then they
are just wrong. They should not double fork; instead, they should
either be supervised by the parent daemon or invoked separately by the
init system. In either case this can be done with waitpid and does
not involve cgroups.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20005.43278.339527.491712@chiark.greenend.org.uk"> http://lists.debian.org/20005.43278.339527.491712@chiark.greenend.org.uk

Minimal init
 

Ian Jackson, le Tue 19 Jul 2011 16:55:58 +0100, a écrit :
> Samuel Thibault writes ("Re: Minimal init [was: A few observations about systemd]"):
> > Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit :
> > > I think messing around with cgroups is a ridiculous way to solve this
> > > problem. The right answer is simply to change the daemons to give
> > > them an option which causes them not to fork. Then you can just have
> > > a single supervision daemon which reaps (and restarts, if desired).
> >
> > But the daemon may want to start external tools, which may double fork.
> > It's a good thing to be able to catch them too.
>
> No, I don't think so. If these external tools double fork then they
> are just wrong.

Well, systemd simply wants to catch that wrong behavior.
Even without talking about double fork, a badly implemented server may
miss to kill some children. system want's to catch that, and it can be a
good thing.

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110719155742.GQ8064@const.famille.thibault.fr">h ttp://lists.debian.org/20110719155742.GQ8064@const.famille.thibault.fr

Minimal init
 

>> It seems this problem (double fork) is the basement of using cgroup
>> under systemd ;)
>
> I think messing around with cgroups is a ridiculous way to solve this
> problem.

To be fair, systemd also uses cgroups to reliably kill rogue child
processes when stopping a service. This is not unlike what BSD-derived
shells use pgroups for, I believe.

> The right answer is simply to change the daemons to give
> them an option which causes them not to fork. Then you can just have
> a single supervision daemon which reaps (and restarts, if desired).

> I haven't done a survey of the available init replacements but this is
> not a new concept

Well, it's already present in SV init :

1:2345:respawn:/sbin/getty 38400 tty1

> and I hope that most of them implement it as a possibility.

Daemontools, runit, minit, upstart, systemd all do. I don't know about initng.

-- Juliusz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 7iy5zu19ux.fsf@lanthane.pps.jussieu.fr">http://lists.debian.org/7iy5zu19ux.fsf@lanthane.pps.jussieu.fr

Minimal init
 

On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
>No, I don't think so. If these external tools double fork then they
>are just wrong.

Double Forking has been the right way to do it for decades. Demanding
from upstreams that they change their software this fundamentally to
cater for a new init system is as unrealistic as demanding from
upstreams to stay around snooping for new IP addresses that came
online after the daemon was started to cater for IPv6.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1QkArf-00049e-I4@swivel.zugschlus.de">http://lists.debian.org/E1QkArf-00049e-I4@swivel.zugschlus.de

Minimal init
 

>>No, I don't think so. If these external tools double fork then they
>>are just wrong.

> Double Forking has been the right way to do it for decades.

It has been the default way for most daemons, granted. (Getty is
a notable exception.)

> Demanding from upstreams that they change their software this
> fundamentally to cater for a new init system is [...] unrealistic

Runit has been around for a decade or so. Most daemons known to me have
a command-line flag that prevents forking.

Remember, preventing forking is about *removing* code from daemons, not
adding new code. Adding a flag to avoid forking is a trivial exercice,
and it's a rare upstream that will refuse the usually trivial patch.

-- Juliusz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hb6epdl9.fsf@trurl.pps.jussieu.fr">http://lists.debian.org/87hb6epdl9.fsf@trurl.pps.jussieu.fr