3

I've just installed Ubuntu on a new build PC and I'm consistently experiencing long boot times of well over 2 minutes. I saw a lot of advice to use systemd-analyze, but wasn't sure how to interpret it for my situation. I've included the output of systemd-analyze and systemd-analyze critical-chain, below. Any help greatly appreciated.

$ systemd-analyze
Startup finished in 7.372s (firmware) + 5.319s (loader) + 3.706s (kernel) + 2min 22.911s (userspace) = 2min 39.309s 
$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2min 22.683s └─multi-user.target @2min 22.683s └─snapd.seeded.service @1min 17.297s +497ms └─snapd.service @32.501s +44.790s └─basic.target @32.359s └─sockets.target @32.359s └─snapd.socket @32.358s +662us └─sysinit.target @32.251s └─systemd-timesyncd.service @31.837s +414ms └─systemd-tmpfiles-setup.service @30.880s +915ms └─systemd-journal-flush.service @4.100s +26.779s └─systemd-remount-fs.service @3.866s +165ms └─systemd-journald.socket @3.526s └─system.slice @3.524s └─-.slice @3.524s

-----Edit----- Hardware Specs:

  • Processor: Intel Core i7-6700K 4 GHz Quad-Core
  • CPU Cooler: Cooler Master Hyper 212 EVO 82.9 CFM Sleeve Bearing
  • Motherboard: Asus B150M-C Micro ATX LGA1151
  • Memory: Corsair Vengeance RGB Pro 32 GB (2 x 16 GB) DDR4-3200 CL16
  • Storage: Seagate BarraCuda 4 TB 2.5" 5400RPM Internal HDD
  • Power supply: be quiet! System Power 9 600 W 80+ Bronze Certified ATX

-----Edit 2----- Output of systemd-anaylze critical-chain after running sudo apt autoremove --purge snapd and sudo reboot.

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 30.725s └─multi-user.target @1min 30.725s └─kerneloops.service @1min 396ms +66ms └─network-online.target @1min 389ms └─NetworkManager-wait-online.service @47.348s +13.040s └─NetworkManager.service @38.520s +8.823s └─dbus.service @38.517s └─basic.target @38.479s └─sockets.target @38.479s └─uuidd.socket @38.479s └─sysinit.target @38.465s └─systemd-timesyncd.service @38.109s +356ms └─systemd-tmpfiles-setup.service @37.043s +1.028s └─systemd-journal-flush.service @4.294s +32.747s └─systemd-journald.service @3.840s +453ms └─systemd-journald.socket @3.837s └─-.mount @3.835s └─system.slice @3.835s └─-.slice @3.835s

2new
  • 31
  • Hello there. Could you provide a bit of detail about your system? Which CPU are you using? How much memory? Things like that. This will help provide some context around why you might be having issues. –  Dec 15 '20 at 07:59
  • It's a well known fact that snaps have a considerable impact on bootup time. Do you have many snaps installed, and are you booting from an old (spinning) HDD? – Artur Meinild Dec 15 '20 at 08:07
  • You're having issue with systemd-journal-flush.service. It takes about 27 seconds to finish. Have a look at this. You might get an idea going through the answers. Another major impact is on snapd (45 seconds). It's snapcraft package manager daemon. You can try removing it by issuing sudo apt autoremove --purge snapd. Check if this reduces boot time by at least 1 minute. Your machine's hardware details would help us identify the problem further. – Jijo Joseph Dec 15 '20 at 08:11
  • Wow, thanks for the quick responses. I've added the hardware specs to the post. – 2new Dec 15 '20 at 08:17
  • Looking at the spec, 2+ minutes of boot time is unexpected. 4TB 5200 RPM HDD might not be a faster hard drive but it shouldn't be more than 1 minute. Try removing snapd as I mentioned above then post another log of systemd-analyze – Jijo Joseph Dec 15 '20 at 08:23
  • Thanks @JijoJoseph, after running sudo apt autoremove --purge snapd it boots a bit faster. It's down from ~2:10 to ~1:40. Still well over a minute, but a big improvement. I've updated the post with the new output of systemd-analyze critical-chain. Any other suggestions? – 2new Dec 15 '20 at 08:39
  • @ArturMeinild I'm not even sure what a snap is. I've not installed anything beyond the OS at this point. – 2new Dec 15 '20 at 08:41
  • this can help. – Raffa Dec 15 '20 at 09:17
  • And this for the long time systemd-journal-flush.service takes: https://askubuntu.com/q/1094389/1037709 – starkus Dec 15 '20 at 11:22
  • In /etc/default/grub replace the value of GRUB_CMDLINE_LINUX_DEFAULT:

    GRUB_CMDLINE_LINUX_DEFAULT="nosplash debug --verbose"

    then run: $sudo update-grub

    This will enable printing of debugging information during the boot sequence. This should inform next time you boot what operation in the boot sequence stalls the critical-chain.

    – pip1726 Dec 15 '20 at 19:38
  • mostly these type of boot delays will come due to something need to get mouunted while booting without actually system having it. in systemd-analyze critical-chain, it is clearly showing boot gaps. will you paste your /var/log/boot.log file? something you can look up for like "timed out waitng for the device..." or "dependency failed for...." in that file – Pavan_open_source Jan 09 '21 at 04:22

0 Answers0