Bug 1782879 - 30 secons boot delay: a stop job is running for udev
Summary: 30 secons boot delay: a stop job is running for udev
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 31
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
: 1781329 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2019-12-12 14:42 UTC by Miguel Angel
Modified: 2019-12-20 12:43 UTC (History)
10 users (show)

Fixed In Version: systemd-243.5-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-12-19 16:24:02 UTC
Type: Bug

Attachments (Terms of Use)
journalctl -b -o short-monotonic (385.58 KB, text/plain)
2019-12-12 14:42 UTC, Miguel Angel
no flags Details

Description Miguel Angel 2019-12-12 14:42:02 UTC
Created attachment 1644447 [details]
journalctl -b -o short-monotonic

Description of problem:
Boot process stops for 30 seconds with the message "A stop job is running for udev Kernel Device Manager"

The exact symptoms described in https://github.com/systemd/systemd/issues/14128 are observed

Version-Release number of selected component (if applicable):
Fedora 31 running systemd-243.4-1.fc31

How reproducible:
Always reproducible on every boot in my DELL latitude e6400

Steps to Reproduce:
1. Boot Fedora

Actual results:
1. System takes more that 30 seconds to boot.
2. If "rhgb" is removed from GRUB's command line, the following systemd message appears for 30 seconds: "A stop job is running for udev Kernel Device Manager"

Expected results:
No extra delay should appear

Additional info:
My laptop dual boots Arch, running systemd-244-1, and it does have such delay
In fact, an Arch user reported this bug upstream

I've attached "boot.log" file which is the result of running "journalctl -b -o short-monotonic"

Note the 30 second gap in:
[    2.923207] latitude-e6440 kernel: Finished initializing topology
[    3.371340] latitude-e6440 kernel: Console: switching to colour frame buffer device 240x67
[    3.394986] latitude-e6440 kernel: i915 0000:00:02.0: fb0: i915drmfb frame buffer device
[   33.601134] latitude-e6440 systemd-udevd[339]: Giving up waiting for workers to finish.
[   33.602015] latitude-e6440 systemd-udevd[339]: Event loop failed: Connection timed out
[   33.604197] latitude-e6440 systemd[1]: systemd-udevd.service: Main process exited, code=exited, status=1/FAILURE
[   33.604767] latitude-e6440 systemd[1]: systemd-udevd.service: Failed with result 'exit-code'.
[   33.604873] latitude-e6440 systemd[1]: Stopped udev Kernel Device Manager.
[   33.605070] latitude-e6440 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[   33.605232] latitude-e6440 systemd[1]: systemd-udevd.service: Consumed 1.757s CPU time.
[   33.605506] latitude-e6440 systemd[1]: systemd-udevd-control.socket: Succeeded.

Comment 1 Miguel Angel 2019-12-12 14:49:53 UTC
My apologies, I meant Arch Linux, running systemd-244-1 does NOT have such delay.

Comment 2 Matthias 2019-12-15 01:33:55 UTC
I observe the same thing with my desktop PC. Using an Asus mother board with Xenon CPU and Nvidia GPU with Nvidia driver from rpmfusion.

This only started recently. Earlier versions of F31 had no problems. I don't know if it is related, but the Plymouth boot screen stopped showing at the same time. Now I only get the black screen until SDDM starts.

Comment 3 Fedora Update System 2019-12-18 01:25:26 UTC
systemd-243.5-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-29767c1981

Comment 4 Fedora Update System 2019-12-18 09:57:59 UTC
FEDORA-2019-29767c1981 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-29767c1981

Comment 5 Phil O 2019-12-18 14:30:26 UTC
Updating to systemd-243.5-1 did not solve the issue for me.

Comment 6 Xose Vazquez Perez 2019-12-18 23:31:00 UTC
*** Bug 1781329 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Update System 2019-12-19 01:23:18 UTC
systemd-243.5-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 8 Phil O 2019-12-19 03:05:32 UTC
Problems still persist.

Comment 9 Zbigniew Jędrzejewski-Szmek 2019-12-19 12:03:32 UTC
Can somebody who is experiencing this attach an updated boot log (like in comment #0)?

Comment 10 Phil O 2019-12-19 16:06:12 UTC
Apologies for the noise.  I noticed that the systemd in initramfs was still on the old version.  I ran "sudo dracut -f" to rebuild initramfs, and now the problem is solved on boot for me (should a systemd update trigger an initramfs rebuild automatically?).  Thanks for the fix.

Comment 11 Zbigniew Jędrzejewski-Szmek 2019-12-19 16:24:02 UTC
Ha, I was suspecting that!

> should a systemd update trigger an initramfs rebuild automatically?

No. Systemd is only one of the things in the initramfs. In principle we could rebuild
the initramfs every time a package that has files that end up in the initramfs gets
updated, but that'd be very unwieldy, since rebuilding of the initramfs is slow,
and we don't have a list of such packages. Also, people have more than one initramfs,
and in principle we would have to rebuild all of them. Apart from being slow, rebuilding
of the initramfs can easily go wrong... In the end, we currently only build the
initramfs on kernel installation and never touch it afterwards.

Comment 12 Miguel Angel 2019-12-20 12:43:54 UTC
Very much the same here: Simply updating the package did not solve the issue, but after rebuilding initramfs

Thanks so much for the fix!

Note You need to log in before you can comment on or make changes to this bug.