<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>