Re: what's the order in which systemd .device units are created ?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 02.06.21 14:00, Abder (koute102030@xxxxxxxxx) wrote:

> Hi,
>
> Even though I've browsed through a lot of resources I haven't found any
> satisfying answer to my question. I've been trying to minimize the booting
> time in the user land on my embedded board, and when I run the classic
> $systemd-analyze plot > plot.svg I saw that there is a non-negligible slot
> of time in which all what systemd does is creating device units that were
> discovered via udev.
>
> My problem is in the order in which these device units are created,
> specially for the block device that contains my rootfs. What I noticed is
> that when these device units are created, the one corresponding to my
> rootfs blockdev partition is always the last one created, causing the other
> services depending on it to wait much more than if the device unit was
> created earlier.
>
> So, I would like to know if systemd follows a special order when creating
> these units, and if yes, what can I do so the device unit of my rootfs
> blockdev partition can be the first one created ?

The systemd-udev-trigger.service unit invokes "udevadm trigger" to
trigger all devices that are already discovered by the kernel at that
point. PID 1 listens to that and synthesizes .device units from all
devices popping up. The order in which "udevadm trigger" triggers them
is pretty much the order in which readdir() returns the devices when
iterating through /sys/, i.e. basically undefined.

There's a github issue open somewhere where I proposed adding a new
switch to "udevadm trigger" called --priorize-subsystem=… or so, which
you can use to priorize on or more subsystems: any subsystems listed
that way are triggered first. That way you could do "udevadm trigger
--priorize-subsystem=block" to ensure block devices are triggered
first (in fact, we probably should use this as default once we have
the concept, given that the most relevant devices we wait for at boot
are probably all block device). Would be happy to review/merge a patch
for that.

Note that the order in which devices are triggered does not directly
translate to the order in which devices actually are processed and
make it through udevd and are picked up by PID 1. udevd runs rules for
each device, and if those are slow and take a bit of time, this might
delay delivery of the events to PID 1. However, there's certainly some
relationship here: if certain devices are the ones we start processing
first thy are likely also the devices where we finish processing them
first, even if there's no strict guarantee for that.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel