Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)"
* Package name: dumb-init
Version : 1.0.0
Upstream Author : Yelp
* URL : https://github.com/Yelp/dumb-init
* License : Expat
Programming Lang: C, Python
Description : minimal i
Steve Langasek writes ("Re: Minimal init [was: A few observations about
systemd]"):
> FWIW, I've gotten feedback from Samba upstream that the upstart job for smbd
> in Ubuntu, which runs the daemon foregrounded, is concerning to them because
> foreground mode hasn't
]] Konstantin Khomoutov
| Doesn't exactly the same problem exist with "classic" daemons?
| I mean, as soon as a daemon being started forked once, the parent
| instance has no idea whether the forked instance actually managed to
| complete initialization, and if it did then when. Unless some sort
On Tue, 2 Aug 2011 15:45:51 -0700
Steve Langasek wrote:
[...]
> There's also the matter that if your daemon is being run in the
> foreground, other services depend on it, and you're not using socket
> activation, there's ambiguity as to when the service is actually
> "started". A racy startup is
On Tue, Aug 02, 2011 at 07:14:31PM +0100, Ian Jackson wrote:
> Marc Haber writes ("Re: Minimal init [was: A few observations about
> systemd]"):
> > On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
> > wrote:
> > >No, I don't think so. If these external
Juliusz Chroboczek writes ("Making daemons compatible with systemd [was:
Minimal init]"):
> > From what I've seen in Lennart's posts, adding systemd support doesn't
> > seem to be too complicated.
>
> No. No changes at all are necessary to be compatibl
Marc Haber writes ("Re: Minimal init [was: A few observations about systemd]"):
> On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
> wrote:
> >No, I don't think so. If these external tools double fork then they
> >are just wrong.
>
> Double Forking has
> From what I've seen in Lennart's posts, adding systemd support doesn't
> seem to be too complicated.
No. No changes at all are necessary to be compatible with systemd.
This is a very impressive feature of systemd; at the same time, this is
what complicates systemd, and creates a dependency on c
On Fri, Jul 22, 2011 at 3:31 PM, Juliusz Chroboczek wrote:
>> From what I've seen in Lennart's posts, adding systemd support doesn't
>> seem to be too complicated.
>
> No. No changes at all are necessary to be compatible with systemd.
> This is a very impressive feature of systemd; at the same ti
On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek
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.
>
> It has been the default way for most daemons, granted. (Getty is
> a notable
>>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 softwar
On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
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
>> 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
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 c
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
On Tue, Jul 19, 2011 at 5:18 PM, Ian Jackson
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.
>
>>
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 daemo
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 ;)
On Tue, Jul 19, 2011 at 4:42 PM, Juliusz Chroboczek 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
> 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
20 matches
Mail list logo
