Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Lennart Poettering]

On Fri, 11.11.11 14:36, Miloslav Trmač (mitr at volny.cz) wrote:

> On Fri, Nov 11, 2011 at 2:22 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Fri, 11.11.11 14:12, Miloslav Trmač (mitr at volny.cz) wrote:
> >
> >> On Fri, Nov 11, 2011 at 2:05 PM, Lennart Poettering
> >> <mzerqung at 0pointer.de> wrote:
> >> > Note that only double-forking
> >> > will properly detach a process from the parent it is started from on
> >> > Unix, and hence is not an option but mandatory to do
> >>
> >> In the traditional SysV, the process executing /etc/init.d/$service
> >> will exit immediately afterwards.  Isn't that structurally equivalent
> >> to double-forking within the service?
> >
> > No.
> >
> > In SysV it is expected that when you run "/etc/init.d/foobar start" and
> > this command completes the service is fully initialized, the PID file
> > written and the service accessible. That means that you need to double
> > fork and in the parent process wait until initialization is
> > complete.
> I can just as well wait in the single-fork parent, can't I?

You can also use inotify to watch the PID file and script gdb to
introspect what the daemon is doing, waiting until it is ready. In fact
you can also smoke some pot and shoot yourself in the foot, then dance a
samba in the rain and finish things off by playing chess on top of a
japanese bullet train.

Just because you can do something doesn't mean it's a good idea though.

And anyway, double forking to daemonize is well documented Unix API, and
why is it suddenly me who has to defend Unix against naysaying folks?
Usually people complain that I'd be the one who shows no respect for the
perfection that Unix supposedly is.

> Again, I should be able to do this in the ultimate child just the same
> - the concept of "orphaned process group" (and the related
> SIGHUP/SIGCONT behavior) only triggers for process groups within a
> single session, and the controlling TTY behavior should not matter for
> daemons (although I do agree that having the session leader exit is a
> little safer because it ensures that the daemon won't randomly obtain
> a controlling TTY).

You want to detach from the controlling tty to make sure that C-c is not
delivered to you and in fact all kill() invocations for process groups.

> I can see only one difference - starting the daemon from a command
> line within a user's session without double forking would leave the
> process "attached" to the user's session in the process tree; however,
> given that the process was not actually started by the service
> management system in that case, this might arguably be considered a
> correct behavior - and in any case doesn't really matter for anything.

Right, because invoking services from a shell script and from the
login shell is the only way you can spawn a service, right? And
because nobody invokes daemons from superviser tools, their own programs
and about any other thinkable way to spawn services. (hell, people even
end up spawning daemons from udev rules!)

You know, I am the one who suggests that people should just drop the
entire forking business entirely, and leave that to the init system
(read: systemd), so if you want to drop forking, then drop forking! Do
it completely! Be my guest, I'd be a very happy man!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.