Snapd delays startup and shutdown of Ubuntu Desktop 20.04

Suddenly today, snapd is delaying startup and shutdown by ~ 10 minutes in each case.

On startup, I get three iterations of “Starting Snap Daemon”, each with a number of cycles through “A start job is running for Snap Daemon,” several of which have countdowns of 3 minutes or more, and then “Failed to start Snap Daemon”.

In the midst of this is an instance of “Started run anacron jobs”, [anacon, really?] followed by “Failed to start Wait until snapd is fully seeded.”

On shutdown, I get a few “Stop job is running on Snap Daemon” with 1’30" countdowns.

No logs, etc., are available because the startup sequence is then followed by a hard hang on “Reached target Graphical Interface.” and I’m working now from a backup laptop.

Any suggestions of a fix would be much appreciated.


Booting the machine to stick, I discovered that /etc/systemd/system/snapd.service, which symlinks to /lib/systemd/system/smartmontools.service, is broken. Double-clicking on the link pops up an error box saying the target doesn’t exist. Nav to the directory and, sure enough, it doesn’t.

What’s interesting is that /lib is itself a symlink to /usr/lib. Nav to /usr/lib/systemd/system and smartmontools.service is there, as are a few other .service files absent from the /lib subdirectory.

I’m not certain what’s up but this clearly is a big issue somewhere. Thoughts?

Why would snapd.service be a symlink to smartmontools.service? snapd.service is shipped by the snapd package and is not a symlink, it’s a real file with content.

I have no idea. I was wondering the same thing myself and was hoping someone here had an idea.

The file does exist, to your point.

Besides the question why the link exists, perhaps the more important question is why the link (and others) fail.

well, snapd.service also usually lives in /lib/systemd, not /etc/systemd … you or someone else must have created that link manually or through some command somehow …

It certainly wasn’t me.

This is a fresh, bare-metal install on a freshly-created hardware RAID 6 array. All I’ve been doing is installing packages, installing drivers (video and printer), and editing configuration files for things like Samba, gdm3, rsyslog, networkd, and VMware Workstation. Just basic stuff.

The only fiddling I do with /etc/systemd/system is to create and enable a few units for periodic backup and to run the iptables script.

Clearly, something is wrong with an installation package somewhere.

Otherwise, I would note that /lib doesn’t exist. It’s a link to /usr/lib. Further, that snapd.service resides in /usr/lib/systemd/system.

Two matters of concern are:

  • snapd’s use of the ironically-named anacron instead of systemd

  • Several bug reports I’ve surfaced in recent days that snapd continues to make reference to /lib and may fail to update links to targets in /usr/lib

Neither *should be* a problem but each is a patch / kludge and as such adds opportunities for failure.

this is by design, expected and wanted since 2019 in ubuntu … debian followed suit in 2021

and originally this is a RedHat feature:

I’m not sure what you mean by this. Snapd does not use anacron for anything.