:: Re: [DNG] tiny service state api [W…
Top Page
Delete this message
Reply to this message
Author: Hendrik Boom
Date:  
To: dng
Subject: Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 15.04.2017 19:50, Steve Litt wrote:
>
> > About my characterizations: "Baroque" is a relative thing. What I wrote
> > was based on "why would you not simply use a process supervisor like
> > systemd?" If a person has a reason not to use such a supervisor, and in
> > fact the whole OpenRC init system seems to be based on such objections
> > to supervisors, then the six system call solution you outline
> > transitions from "a whole bunch of needless stuff" to "hey, that's a
> > pretty darn kool solution." So your solution is baroque only so far as
> > one enjoys using daemontools or similar.
>
> If one doesn't want a supervisor, why not just using something like
> start-stop-daemon ? IIRC, it should handle that quite well.
>
> I wonder why that general task of daemonizing cant just be done in a
> generic separate program and left out of the individual daemons.
> So, everybody can decide on this own how to actually start/manage
> the daemons - some use a supervisor, some just call via a daemonizer
> program from init scripts, etc, etc.
>
> By the way: maybe we should write an RFC draft for the whole issue ...


Looked for a relevant RFC. But found only this:
https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
[RFC] [PATCH] notify init daemon when children are reparented to it

But this doesn't seem to be quite what we want, and I can't say I have
enough context to understand it.

It seemms to follow the practice of creating two processes for a
daemon, a parent and a child, and then orphaning the child.
This is not what we seem to be discusison here, and leads to
init having nontrivial ongoing work.

And although it says [RFC] in the title, it doesn't seem to be an
official RFC.

-- hendrik

>
>
> --mtx
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng