FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-22-2011, 04:52 PM
Fernando Lemos
 
Default Minimal init

On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> 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 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.

Well, to be fair, preventing forking is *adding* code to parse the
right option and skip the calls that do the double forking. It should
be, though, a fairly simple change.

>From what I've seen in Lennart's posts, adding systemd support doesn't
seem to be too complicated. Some bigger changes may be required for
more complex daemons. It's understandable that upstream might not
accept them at first. In an hyphotetical scenario where systemd
becomes the default init system in Debian, not having a systemd init
file could be an overridable lintian warning or something like that.

I'd like to stress that systemd apparently handles LSB scripts pretty
well, even running them in parallel whenever possible. I find it
perfectly natural that it'll take time for some upstreams to get
confortable merging those patches. Package maintainers that prefer not
to ship those patches could opt to ship a SysV init script instead.
This backwards compatibility isn't going away in the foreseeable
future.

I also think it wouldn't be wise for an upstream to ignore systemd
compatibility patches unless those require massive changes to the code
(which could be a symptom of more serious upstream problems or perhaps
bad design decisions).


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANVYNa83Qdvm3x-6TxuqbOs0k_eqTEC3-F_8dHx9A37PcqygAQ@mail.gmail.com">http://lists.debian.org/CANVYNa83Qdvm3x-6TxuqbOs0k_eqTEC3-F_8dHx9A37PcqygAQ@mail.gmail.com
 
Old 08-02-2011, 06:14 PM
Ian Jackson
 
Default Minimal init

Marc Haber writes ("Re: Minimal init [was: A few observations about systemd]"):
> 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.

However it is very easy to patch daemons to have an option which
causes them not to fork. Most daemons /already/ have a mode in which
they don't fork, for debugging purposes.

I think we should be quite happy to carry those patches forever, for
the few upstreams who won't take them.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20024.16007.757337.635075@chiark.greenend.org.uk"> http://lists.debian.org/20024.16007.757337.635075@chiark.greenend.org.uk
 
Old 08-02-2011, 10:45 PM
Steve Langasek
 
Default Minimal init

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
> > <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.

> However it is very easy to patch daemons to have an option which
> causes them not to fork. Most daemons /already/ have a mode in which
> they don't fork, for debugging purposes.

> I think we should be quite happy to carry those patches forever, for
> the few upstreams who won't take them.

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 been tested upstream in about a decade. No bug
reports yet about actual breakage, but if not for the fact that smbd manages
to bewilder upstart's daemon tracking code when allowed to daemonize (fix
coming soon), I would switch the job to invoke smbd in the usual fashion.

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 a
bad thing.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 08-03-2011, 09:04 AM
Konstantin Khomoutov
 
Default Minimal init

On Tue, 2 Aug 2011 15:45:51 -0700
Steve Langasek <vorlon@debian.org> 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 a bad thing.
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 of
communication channel is used.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110803130431.19f47c10.kostix@domain007.com">http ://lists.debian.org/20110803130431.19f47c10.kostix@domain007.com
 
Old 08-03-2011, 09:20 AM
Tollef Fog Heen
 
Default Minimal init

]] 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 of
| communication channel is used.

A well-behaved double-forking daemon doesn't do the second fork until
it's ready to serve requests.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vrakg0r.fsf@qurzaw.varnish-software.com">http://lists.debian.org/878vrakg0r.fsf@qurzaw.varnish-software.com
 
Old 08-03-2011, 02:10 PM
Ian Jackson
 
Default Minimal init

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 been tested upstream in about a decade. No bug
> reports yet about actual breakage, but if not for the fact that smbd manages
> to bewilder upstart's daemon tracking code when allowed to daemonize (fix
> coming soon), I would switch the job to invoke smbd in the usual fashion.

If the code is in upstream already then clearly we don't have a
problem getting it into upstream. All that's needed is for it to be
fixed, and upstream will take those fixes.

> 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 a
> bad thing.

I agree. But using a daemon's call to fork() as a proxy for startup
notification is IMO absurd.

Also I have no objection to socket activation (which is after all
what inetd does...).

Ian.


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

Thread Tools




All times are GMT. The time now is 02:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org