| Summary: | every boot hangs for ~20s at a random stage | ||
|---|---|---|---|
| Product: | systemd | Reporter: | yzb3 <yzb3> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED WORKSFORME | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | david |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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.
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.