Re: upstart: please update to latest upstream version

[Goswin von Brederlow <goswin-v-b@web.de>]

Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>> Vincent Bernat <bernat@debian.org> writes:
>>> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>>>> That would actually make things more difficult since then you have to
>>>> add some delay into the sysvinit files to wait for the daemon to
>>>> become ready before the init.d script returns.
>
>>> Is start-stop-daemon actually relying on the PID file being created to
>>> know if the daemon is ready? Or maybe you mean a daemon fork only when
>>> it is ready?
>
>> The later.
>
> Indeed, that's the problem with a pure runit-style system.  (A lot of
> runit systems and daemontools systems don't worry too much about
> dependencies and just assume that things will exit and be restarted until
> they're successful, but that doesn't really scale.)
>
> However, it's probably addressable.  For most programs that are meaningful
> as dependencies of other programs, there's some visible and probeable sign
> that the daemon has finished startup: the creation of a UNIX domain
> socket, a named pipe, a TCP or UDP listening socket, etc.  I could see
> just telling the init system what to look for to know that the daemon has
> started.

I think all of those would be better solved with socket activated
startup thingy. For sysvinit systems this could look something like
this:

start-stop-daemon --start --quiet --exec /usr/bin/dns-server --oknodo \
  --pidfile /var/run/nbd-server.pid --socket-udp dns

start-stop-daemon --start --quiet --exec /bin/nbd-server --oknodo \
  --pidfile /var/run/nbd-server.pid --socket-tcp 10809

start-stop-daemon --start --quiet --exec /usr/bin/gdm --oknodo \
  --pidfile /var/run/gdm.pid --socket-unix /tmp/.X11-unix/X0

start-stop-daemon --start --quiet --exec /usr/bin/piper --oknodo \
  --pidfile /var/run/gdm.pid --pipe /var/run/piper.pipe

and so on. The way this would work would be that start-stop-daemon
creates the socket or pipe, then forks the daemon and passes the FD
along eigther through stdin/stdout or systemds syntax. The service would
be ready to recieve connects as soon as start-stop-daemon has created
the socket or pipe (even though it will no process them just yet). And
with the creation being under start-stop-daemons control it knows when
it is safe to return.

Start-stop-daemon could even support waiting for the first connect
before actually starting a daemon.

Same with runit.

MfG
        Goswin