Recently I noticed that my boot has become much slower than before. I ran systemd-analyze, which reports a silly value: Startup finished in 584542y 2w 2d 20h 1min 44.604s (loader) + 2.007s (kernel) + 28.255s (userspace) = 30.262s I tried to identify the culprit service by running systemd-analyze critical-chain, but it hangs for around 20s at random stages of boot (this time at sysinit.target, but on previous boot it was systemd-tmpfiles-setup.service, sometimes it is timers.target or basic.target... you get the point): multi-user.target @28.255s └─systemd-logind.service @28.037s +217ms └─basic.target @28.036s └─timers.target @28.035s └─systemd-tmpfiles-clean.timer @28.035s └─sysinit.target @2.443s └─systemd-update-utmp.service @2.306s +136ms └─systemd-tmpfiles-setup.service @2.219s +87ms └─local-fs.target @2.218s └─home.mount @2.148s +70ms └─dev-disk-by\x2duuid-c26e6d9a\x2d0bbb\x2d436a\x2da217\x2d95c738b5b9c6.device @2.148s #journalctl -b also doesn't help, not even with the systemd debug kernel parameter - the point at which the boot pauses for around 20s is random and debug provides no additional [relevant] information. systemd-analyze blame reports no service that would explain this pause: 439ms systemd-udev-trigger.service 434ms systemd-sysctl.service 433ms systemd-vconsole-setup.service 433ms sys-kernel-debug.mount 217ms systemd-logind.service 206ms kmod-static-nodes.service 136ms systemd-update-utmp.service 88ms sys-kernel-config.mount 88ms dev-hugepages.mount 87ms systemd-tmpfiles-setup.service 86ms systemd-remount-fs.service 86ms tmp.mount 70ms home.mount 54ms systemd-user-sessions.service 46ms systemd-tmpfiles-setup-dev.service 37ms user@1000.service 27ms systemd-backlight@acpi_video0.service 20ms systemd-journal-flush.service 17ms systemd-udevd.service 15ms systemd-random-seed.service 5ms dev-mqueue.mount 5ms alsa-restore.service Please advise whether I can provide any additional information that could help resolve this.
Well, it probably won't hurt to add that I'm using a fully updated Arch Linux with the current mainline kernel and systemd 208.
Is this still an issue with 209?
I wonder if the root cause is the same as the one we found where a stage of boot would hang 60 seconds per log line. We have only verified that on v208, though.
> Is this still an issue with 209? Hi, I have reformatted my HDD a few times since then - it might have been an issue with btrfs caching, since I have not been able to reproduce this with ext4. You may close the bug. Thanks, yzb3
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.