Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian"):
> Is there a more complete explanation of this somewhere? The cookbook is
> rather short on details.
It's documented in upstart's init(5) under "expect stop".
http://manpages.debian.net/cgi-bin/man.cgi?query=init&sektion=5&apropos=0&manpath=Debian+testing+jessie&locale=
> Assuming that this means the daemon sends SIGSTOP to itself when it's
> ready to accept connections, I find this completely counter-intuitive and
> exceedingly strange. Wouldn't this cause the daemon, if run outside of
> upstart, to do nothing in an extremely confusing fashion? I assume
> upstart is using waitpid to wait for the child to be stopped and is
> sending SIGCONT, and if you run the daemon outside of that environment, it
> would just stop itself and never start again.
The daemon only does this if you tell it to, typically with a command
line option. If you were to run it with that option from the shell,
your shell would report that the daemon had stopped much as if you had
^Z'd it (although ^Z generates SIGTSTP).
Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > It comes with being the daemon's parent, even - the special powers of
> > pid 1 aren't even needed.
>
> I'm not sure that I understand. This is in the context of handling
> daemons that fork and background themselves, is not it?
No. It's in the context of daemons which are written (well, have been
modified) _not_ to fork. They just run as children of the supervisor.
It's a way for a daemon to signal that it is ready.
Running daemons directly as children of the supervisor is not a new
idea: inetd does it for network servers (although it gets the logging
wrong) and Dan Bernstein's daemontools work this way too.
systemd supports the non-forking daemon too. Only, instead of
raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
environment variable, connect to it, and send a special message with
socket credentials attached.
> If so, no normal parent would be able to detect that this has
> happened because the process would have already been reparented by
> init before the SIGSTOP signal is sent. So it does rely on the
> special properties of PID 1, namely its adoption of all processes
> that have abandoned their parent process.
The SIGSTOP protocol is an alternative to the traditional daemon(3)
call. daemon(3) is IMO at the root of the problem with sysvinit.
Ian.
Reply to: