Skip to main content ↑ ↓
Topic: The need for udevd-early in dinit (Read 2201 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The need for udevd-early in dinit

Hi all!

I've recently played a bit with udev alternatives in Artix (returned after 4 years), this time using dinit as init. While ripping out udev scripts from system, i found that there are actually separate scripts udevd-early and udevd, where the former does not implement supervision. Do we really need such scheme in dinit? It looks like runit legacy where population at stage 1 was separate from running udev in stage 2. While i tested alternative only in qemu, it was enough to use only one daemon script + one trigger.
ARMtix
If you need to contact me, use email

Re: The need for udevd-early in dinit

Reply #1 –
It's been a while since I looked at udev so I'm not 100% certain but IIRC the problem is that the "trigger" step (which runs something like udevadm trigger --action=add) cannot be run until udevd has itself fully started. But, udevd doesn't support readiness notification (at least, it doesn't support non-systemd readiness notification...) so you have to run it as an unsupervised daemon in order to get an effective readiness signal (i.e. it is ready when it backgrounds itself and the foreground process terminates).

Probably you were just lucky in your own testing - there was enough time between udev starting and the trigger so that the trigger could actually run successfully.

So the options are either that you run udevd unsupervised, use some hack (eg sleep for a fixed interval before running "trigger" and hope that it's long enough) or you run unsupervised only as long as necessary to do the trigger, then you stop it and start it again but supervised this time (i.e. what Artix is doing, though still seems hacky and I'm not sure it's race free).

I did write a patch to eudev to support notification for S6 and dinit, here: https://github.com/eudev-project/eudev/pull/290

But, it seems eudev is no longer maintained :(

Re: The need for udevd-early in dinit

Reply #2 –
Quote from: davmac – on
Probably you were just lucky in your own testing - there was enough time between udev starting and the trigger so that the trigger could actually run successfully.
Just checked s6 and openrc versions - neither of them have separate early udev.
Technically, even without readiness notifications you can start udev service properly (i.e. not as in early script) and add delay directly to trigger script
ARMtix
If you need to contact me, use email

Re: The need for udevd-early in dinit

Reply #3 –
Just looked at runit and /etc/rc/sysinit contains the links in the order 30-udev, 31-udev-trigger,  32-modules & 33-udev-settle

Re: The need for udevd-early in dinit

Reply #4 –
Quote
Technically, even without readiness notifications you can start udev service properly (i.e. not as in early script) and add delay directly to trigger script

I guess you could poll for existence of /run/udev/control before running the trigger, for example.

Re: The need for udevd-early in dinit

Reply #5 –
@konimex As dinit implementation maintainer, could you please take a look at this thread?
ARMtix
If you need to contact me, use email

Re: The need for udevd-early in dinit

Reply #6 –
I'll have to check later, but I remember that (either) unlocking encrypted partition or locking it on shutdown hangs my system when I tried to do it your way.

Note that Chimera Linux, which I use as one of the sources of Artix rc services, also do udev this way.
now only the dinit guy in artix