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
Attachment:
signature.asc
Description: Digital signature