(Dropping original bug, adding cloned bug, full quote for context) On Wed, Oct 10, 2018 at 4:38 AM Guillem Jover <guil...@debian.org> wrote:
> 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 <bi...@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
