Re: upstart: please update to latest upstream version
Russ Allbery <email@example.com> writes:
> Goswin von Brederlow <firstname.lastname@example.org> writes:
>> Vincent Bernat <email@example.com> writes:
>>> Goswin von Brederlow <firstname.lastname@example.org> 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
I think all of those would be better solved with socket activated
startup thingy. For sysvinit systems this could look something like
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.