(Dropping original bug, adding cloned bug, full quote for context)
Hi!
On Tue, 2018-10-09 at 22:01:21 -0300, Felipe Sateler wrote:
> Control: clone -1 -2
> Control: retitle -2 start-stop-daemon: please implement service readiness protocol
> Control: severity -2 wishlist
> On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl <biebl@debian.org> wrote:
> > The only supported way in udev to signal readiness is the sd-notify API.
> > My gut feeling is, that having an sd-notify wrapper for non-systemd
> > systems (e.g. directly built into start-stop-daemon via say an
> > --wait-for-sd-notify switch) would be the cleanest and most robust way.
> > This might even benefit other daemons besides udevd.
>
> Indeed, it seems to me that start-stop-daemon supporting the same service
> readiness protocol systemd implements[1] would make things easier for udev
> and other services.
>
> Short description for those not familiar: the service manager (or ssd in
> this case) sets up a AF_UNIX socket, and passes on the address to the
> daemon via the NOTIFY_SOCKET environment variable. When the daemon sends a
> message containing READY=1, then ssd should consider the service up and it
> can exit. More details at the linked manpage.
Hah, this is already almost implemented. Was planning on finishing the
couple of XXX (including setting the envvar) and docs, testing and
merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/s-s-d-notify>
Awesome. This should help a lot.
--
Saludos,
Felipe Sateler