Russ Allbery <r...@debian.org> writes:
> Goswin von Brederlow <goswin-...@web.de> writes:
>> Vincent Bernat <ber...@debian.org> writes:
>>> Goswin von Brederlow <goswin-...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx7mayw9.fsf@frosties.localnet
