[systemd-devel] Waiting udev jobs

[Alan Perry]

I occasionally see a problem where systemd-analyze reports that boot
did not complete and it is suggested that I use systemctl list-jobs
to find out more. That shows a .device service job and some sub-jobs
(associated with udev rules) all waiting. They will wait for literal
days in this state. When I accessed the system, it wasn’t apparent
what the jobs were waiting on since all of the device symlinks and
such were there and working. The systemctl status of the .device
service was alive.
Any suggestions on what is going on and/or how to figure out what is
going on?
If you have followed my posts here previously, it should come as no
surprise that the device that I observed this happen with was one of
the emmc boot devices.

This is not enough information. Please provide "systemctl status" info
on the relevant units and jobs, please provide a dump of the output.
And most importantly, always start with the systemd version number you
are using, and whether you have any weird udev rules or so, or just
plain upstream stuff.

While I am now looking at a specific problem, I am asking a general question. There might be future situations where I see a udev job waiting. Is there a general way to find out what it is waiting on? Does it depend on what systems version is being run?

I can answer the questions you asked later. I don’t have all of the answers off the top of my head.

alan

Lennart
--
Lennart Poettering, Berlin

[Luca Boccassi]

I occasionally see a problem where systemd-analyze reports that boot
did not complete and it is suggested that I use systemctl list-jobs
to find out more. That shows a .device service job and some sub-jobs
(associated with udev rules) all waiting. They will wait for literal
days in this state. When I accessed the system, it wasn’t apparent
what the jobs were waiting on since all of the device symlinks and
such were there and working. The systemctl status of the .device
service was alive.
Any suggestions on what is going on and/or how to figure out what is
going on?
If you have followed my posts here previously, it should come as no
surprise that the device that I observed this happen with was one of
the emmc boot devices.

This is not enough information. Please provide "systemctl status" info
on the relevant units and jobs, please provide a dump of the output.

I don't have access to that info at the moment. IIRC ...
dev-disk-by\x2dpath-platform\x2d68cf1000.sdhci\x2dboot0.device and
sys-devices-platform
mc0:0001-block-mmcblk0-mmcblk0boot0.device returned
"Active: inactive(dead)" and not much else.
dev-mmcblk0boot0.device returned "Active: active (plugged)". There was
more, but I don't remember what else.

And most importantly, always start with the systemd version number you
are using,

v247 plus patches

And for completeness, the patches on top are just backports from yours
truly, nothing weird, and nothing touching udev or rules apart from
this:

https://github.com/systemd/systemd/commit/8db704b28b4fd4d13e

and whether you have any weird udev rules or so, or just
plain upstream stuff.

plain, upstream rules.
I am trying to figure out what to look at when I have access to the
system exhibiting the problem that I am trying to resolve.
alan