I believe Snapd is the culprit for my slow starts on my SSD-based 20.04 install.
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 37.472s
└─multi-user.target @1min 37.472s
└─snapd.seeded.service @1min 32.099s +28ms
└─snapd.service @1min 30.687s +1.410s
└─basic.target @1min 30.640s
└─sockets.target @1min 30.640s
└─snapd.socket @1min 30.640s +584us
└─sysinit.target @1min 30.631s
└─systemd-timesyncd.service @3.280s +446ms
└─systemd-tmpfiles-setup.service @3.208s +62ms
└─local-fs.target @3.190s
└─run-user-110-gvfs.mount @1min 32.192s
└─run-user-110.mount @1min 31.677s
└─local-fs-pre.target @584ms
└─lvm2-monitor.service @489ms +95ms
└─systemd-journald.socket @481ms
└─system.slice @478ms
└─-.slice @478ms
apt list snapd
Listing... Done
snapd/focal,now 2.44.3+20.04 amd64 [installed]
snap version
snap 2.45
snapd 2.45
series 16
pop 20.04
kernel 5.4.0-7634-generic
systemd-detect-virt
none
I don’t know how anything can take a 1min to start on SSD even if that drive isn’t the fastest one. Also not only snap related services take more than one minute on your install. Maybe the problem lies in something else than snap.
Take a look for example at “run-user-110-gvfs.mount @1min 32.192s” and “run-user-110.mount @1min 31.677s” they both take as much time as the snap services.
On my installation of Ubuntu 20.04 LTS started today it looks like this:
$ 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 @4.879s
└─multi-user.target @4.879s
└─snapd.seeded.service @3.170s +15ms
└─snapd.service @1.965s +1.203s
└─basic.target @1.909s
└─sockets.target @1.909s
└─snapd.socket @1.908s +553us
└─sysinit.target @1.903s
└─systemd-timesyncd.service @1.692s +210ms
└─systemd-tmpfiles-setup.service @1.658s +32ms
└─local-fs.target @1.653s
└─run-snapd-ns-canonical\x2dlivepatch.mnt.mount @3.042s
└─run-snapd-ns.mount @2.924s
└─swap.target @302ms
└─swapfile.swap @226ms +75ms
└─systemd-remount-fs.service @217ms +8ms
└─systemd-journald.socket @209ms
└─-.mount @206ms
└─system.slice @206ms
└─-.slice @206ms
And the whole startup:
$ systemd-analyze
Startup finished in 3.230s (kernel) + 12.323s (userspace) = 15.553s
graphical.target reached after 4.879s in userspace
The help text states that those services start at that time, not that they take that time to start. The text suggests it is the time after the “+” which shows the time a service takes to start. I’ve been doing a bit of searching and haven’t found anything which contradicts this, but the documentation is horribly vague.
Yes you are right I didn’t pay enough attention to that text.
Anyway it still means that graphical target is reached after 1 and half minute and that’s awfully long on SSD.
So does that mean that services which don’t have anything printed with “+” take that long to start. If so than the problem definitely doesn’t come from snapd.
@kendoori Could you also post what sytemd-analyze and systemd-analyze blame show.
I am now of the opinion that this is NOT snap related… but the comments here have helped and if you guys are willing to help me further sherlock this, I appreciate it.
systemd-analyze
Startup finished in 11.606s (firmware) + 608ms (loader) + 7.354s (kernel) + 1min 37.694s (userspace) = 1min 57.264s
graphical.target reached after 1min 37.472s in userspace
It looks like the problem for this user was related to external USB devices.
Also I wonder if the realtime is really that long. I mean does the time when you start your computer and reach a graphical environment is really 1min 30sec. Maybe those services take time to start in the background and you can actually use your system earlier.
graphical.target reached after 1min 37.472s in userspace
1min 30sec is default time to wait for service to start-up in systemd. My graphical.target is 9.265s. To me this looks like something is blocking boot until it times out.
I believe this is solved. I had another SSD of similar size and cloned to the other drive to eliminate the drive being the problem. The side effect of the cloning is that UUID for the swap didn’t properly match the fstab or crypttab entries. I turned swap off, deleted the swap partition, and removed the entries fstab and crypttab and now we are booting in under 11 seconds!
graphical.target reached after 10.391s in userspace
It is possible the fstab etc… were problems before, but not looking back at this point. Definitely NOT a Snap issue.
