<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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?<br><br><div dir="ltr">- -</div><div dir="ltr">Elbek</div><div dir="ltr"><br><blockquote type="cite">On Apr 12, 2022, at 2:00 PM, Mantas Mikulėnas <grawity@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov <<a href="mailto:emm.boxinuse@gmail.com">emm.boxinuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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 <span style="font-family:monospace">.rules</span> 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.<br clear="all"></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>
</div></blockquote></body></html>