Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

Felipe Sateler-2
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 <[hidden email]> 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.

--

Saludos,
Felipe Sateler
Reply | Threaded
Open this post in threaded view
|

Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

Guillem Jover
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 <[hidden email]> 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>

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Bug#908796: udev (with sysvinit) fails to find devices at boot

Felipe Sateler-2
(Dropping original bug, adding cloned bug, full quote for context)

On Wed, Oct 10, 2018 at 4:38 AM Guillem Jover <[hidden email]> 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 <[hidden email]> 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