On graph I have mmcblk.device taking 1.624s. From the point that this partition
is where my rootfs lies, and systems does remounting of rootfs, I did look up
for systemd-remount-fs.service, it took 231ms, and
systemd-udev-trigger.service, as you suggested, it took 517ms to become active.
But even after systemd-udev-trigger.service becomes active there is about 800ms
for mmcblk.device to become active. Are those services related to the
activation of the mmcblk.device? Can I consider those 231ms and 517ms as a part
of the activation time of the mmcblk.device? How can I debug udev in this case?
- -
Elbek
> On Apr 12, 2022, at 2:00 PM, Mantas Mikulėnas wrote:
>
>
>> On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov
>> wrote:
>> How to track down the lifespan of the device unit file, i.e. the activating
>> state? I have an embedded system where systemd-analyze plot shows that the
>> unit file I am interested in, let’s say dev-mmcpartition.device, takes about
>> 2 seconds to be become active. This partition (mmcpartition) holds my
>> rootfs. I would like to know what is going on during those 2 seconds, what
>> device unit file is doing, how to track what it is doing? Thanks in advance.
>
> Really the only thing a .device unit "does" is wait for udev to report that
> the corresponding actual device is ready. As soon as udev sends out the
> uevent with ACTION=add and systemd receives it, the .device unit becomes
> active, that's all.
>
> So if that's slow, it might be the kernel not sending the initial 'add' event
> *to* udev (AFAIK, systemd-udev-trigger.service is responsible for triggering
> fake 'add' events for devices that already exist at boot time, so check where
> that service shows up on the graph), or it might be udev taking a long time
> to process its .rules for that device, or systemd not catching up fast
> enough... Such delays for the mmcblk rootfs seem to be a frequent question
> both here on the list as well as on IRC, but I don't think I remember any
> specific answers.
>
> --
> Mantas Mikulėnas
