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 <ijack...@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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
