Snappy daemon reaches 1min30s timeout during shutdown process

[Francois Thirioux]

Really annoying, it happens very very often at shutdown.

$ snap --version
snap 2.44.3+20.04
snapd 2.44.3+20.04
series 16
ubuntu 20.04
kernel 5.4.0-24-generic

$ snap list
Nom Version Révision Suivi Éditeur Notes
core18 20200311 1705 latest/stable canonical✓ base
foliate 2.1.1 142 latest/stable johnfactotum -
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable canonical✓ -
gnome-3-34-1804 0+git.2c86692 24 latest/stable/… canonical✓ -
gtk-common-themes 0.1-30-gd41a42a 1502 latest/stable/… canonical✓ -
snap-store 20200415.e028804 394 latest/stable/… canonical✓ -
snapd 2.44.1 6953 latest/stable canonical✓ snapd
sweethome3d-homedesign 6.2 9 latest/stable jibel -
zork 1.0.2 3 latest/stable almejo -

[Paul White (paulw2u)]

I'm seeing this too. It took me a while to realise that pressing the 'Escape' key would allow me to watch the count reach 1m30s after which shutdown or reboot would proceed normally.

[Ian Johnson (anonymouse67)]

Hi, can you paste logs for snapd from an affected boot? i.e. run

journalctl -e --no-pager -b -1 -u snapd

if the issue happened for you on the previous boot.

[Paul White (paulw2u)]

Hi Ian, I've shutdown and restarted several times since my comment above and I'm not seeing any delays on shutting down or rebooting now. But here are a some extracts from the last two weeks:

Apr 08 11:46:59 n1644 systemd[1]: Stopping Snap Daemon...
Apr 08 11:47:24 n1644 snapd[980]: daemon.go:583: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: Killing process 980 (snapd) with signal SIGKILL.
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: Failed with result 'timeout'.
Apr 08 11:48:29 n1644 systemd[1]: Stopped Snap Daemon.
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
Apr 08 11:48:29 n1644 systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (systemd-fsck@dev-disk-by\x2duuid-bb3ea850\x2d7b5c\x2d435f\x2d82d4\x2dd9961eecfbd4.service has 'stop' job queued, but 'start' is included in transaction).

Apr 09 22:45:14 n1644 systemd[1]: Stopping Snap Daemon...
Apr 09 22:45:39 n1644 snapd[981]: daemon.go:583: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: Killing process 981 (snapd) with signal SIGKILL.
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: Failed with result 'timeout'.
Apr 09 22:46:44 n1644 systemd[1]: Stopped Snap Daemon.
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
Apr 09 22:46:44 n1644 systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (sysinit.target has 'stop' job queued, but 'start' is included in transaction).

Apr 18 15:10:21 n1644 systemd[1]: Stopping Snap Daemon...
Apr 18 15:10:21 n1644 snapd[985]: main.go:155: Exiting on terminated signal.
Apr 18 15:10:46 n1644 snapd[985]: daemon.go:583: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: Killing process 985 (snapd) with signal SIGKILL.
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: Failed with result 'timeout'.
Apr 18 15:11:51 n1644 systemd[1]: Stopped Snap Daemon.
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
Apr 18 15:11:51 n1644 systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (swapfile.swap has 'stop' job queued, but 'start' is included in transaction).

[Francois Thirioux (fthx)]

I noticed today a difference between 20.04 native and 19.10 upgrade. Upgrade : snapd snap have to be installed to install snap-store (ubuntu-20.04 channel). Native : snapd snap is not installed. Don't know if it's related.

[Francois Thirioux (fthx)]

Well, I managed to install snaps like in native 20.04 and since that moment I do not experience any 1m30s timeout issue. Maybe it's not the solution, it has to be tested for some shutdowns.

In my Focal (19.10 upgrade) without any snap stuff installed:

First, obviously...:
apt install snapd

To not do:
snap install snap-store
because it installs snapd snap

To do:
snap install core
snap install core18
snap install snap-store --channel=stable/ubuntu-20.04
next refresh gnome and gtk-themes to the according channel
and following this way I don't have snapd installed

Well, I don't know if this will avoid the timeout issue but here I see two problems, as far as I can understand from my user POV:
1) installing snap-store snap does not install the Focal's attended snaps
2) installing snap-store from the 20.04 channel does not install gnome-3-34 and gtk-themes accordingly through the same 20.04 channel

[Ian Johnson (anonymouse67)]

This issue does appear to be specific to using the snapd snap, since the snapd.failure unit is the service that gets triggered after the snapd service proper fails to exit gracefully.

If someone does hit this again, it would be useful to see output from

snap changes

ASAP after the slowdown happens on shutdown. The logs from Paul clearly indicate that snapd thinks it needs to do something at that moment, if it is happening frequently it's highly unlikely it's an automated refresh I think.

Also @fthx, note that on a fresh install of 20.04, the snapd snap is already included in the seed. It depends quite a bit on what was in your 19.10 (or earlier) install if you end up getting the core snap snapd service or the snapd snap snapd service.

[Francois Thirioux (fthx)]

Ok I still experience this bug, roughly 75 % of shutdowns.

"snap changes" don't return anything relevant, just a void refresh this morning.

[Maciej Borzecki (maciek-borzecki)]

@paulw2u the logs suggest the snapd snap is either from beta or edge channels, can you confirm?

Anyone experiencing the problem, can you try snapd from the beta channel? `snap refresh --beta snapd`.

[Paul White (paulw2u)]

I'm a little confused now as my "n1644" installation doesn't have the snapd snap installed:

paul@n1644:~$ snap list
Name Version Rev Tracking Publisher Notes
canonical-livepatch 9.5.5 95 latest/stable canonical✓ -
chromium 81.0.4044.129 1135 latest/stable canonical✓ -
core 16-2.44.3 9066 latest/stable canonical✓ core
core18 20200427 1754 latest/stable canonical✓ base
gnome-3-28-1804 3.28.0-16-g27c9498.27c9498 116 latest/stable/… canonical✓ -
gnome-3-34-1804 0+git.2c86692 27 latest/stable canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
snap-store 3.36.0-74-ga164ec9 433 latest/stable/… canonical✓ -

This is an installation that was upgraded from 19.10 to 20.04 as long ago as last November. As far as I can recall I've only ever seen the snapd snap installed on much newer installations on other machines but never on this one, i.e. "n1644". I've not seen the timeout on any of those other installations.

[Francois Thirioux (fthx)]

That's odd.
In a clean VM 20.04 installed maybe 3 weeks ago, I get (sorry for encoding glitches) :

$ snap list
Nom Version R\u00e9vision Suivi \u00c9diteur Notes
core 16-2.44.3 9066 latest/stable canonical\u2713 core
core18 20200427 1754 latest/stable canonical\u2713 base
gnome-3-34-1804 0+git.2c86692 27 latest/stable/\u2026 canonical\u2713 -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/\u2026 canonical\u2713 -
snap-store 3.36.0-74-ga164ec9 433 latest/stable/\u2026 canonical\u2713 -

No snapd here, only core.
Well, I refreshed core to the beta channel (including afics snapd 2.45), I'll give some feedback after some shutdowns.

[Francois Thirioux (fthx)]

Changed to candidate channel for core, sorry.
It seems that 9209 > 9160...

[Ian Johnson (anonymouse67)]

Sorry if I wasn't clear on this, but if you upgraded from 19.10 to 20.04 then AFAIK you will not have gotten the snapd snap at all. The snapd snap will only automatically get installed with a fresh, recent, installation. I don't have a more precise definition of "recent", other than the released images have the snapd snap and some older pre-release ones don't have the snapd snap.

Paul, are you saying that you see this slowdown at boot on your installations that were upgrades (and thus don't have the snapd snap, but instead have the core snap)?

Also to clarify an earlier point I made, the snapd.failure service does actually get installed with the snapd deb package or the core snap, it just effectively does nothing when the snapd snap is not installed. So the fact that it is run doesn't really affect anything. This bug is just about the fact that snapd is busy doing something when the system goes to shutdown, the fact that the snapd.failure.service not getting queued and thus not running is just a red herring here.

[Francois Thirioux (fthx)]

There is a timeout issue for both snapd and core.
Initial bug report description was made with snapd installed.

I reverted to core beta channel, since I did not see at first that candidate does not use snapd 2.45. I'll check that when I'll have time, maybe tonight.

[Paul White (paulw2u)]

Ian, Yes that is correct I only see this slowdown or timeout on this one upgraded installation that doesn't have the snapd snap.

However, I rebooted immediately prior to replying here and no timeout. I reboot most days due to kernel updates or needing to boot into another Ubuntu installation but the only dates on which I have seen the timeout since my comment #3 have been April 23, 28 and 29 - nothing since then.

[Francois Thirioux (fthx)]

Timeout issue with core 16-2.45~pre1 (9160) too.
I try with candidate (snapd 2.44.5).

[Francois Thirioux (fthx)]

So far I did not have a timeout issue with snapd 2.45~pre2+.
3 or 4 shutdowns.
With 2.44.x, snapd or core, the bug was here.

PS: I installed a Focal VM with current files and, yes, snapd is installed, not core. But I'm 100 % sure it was core in my some-weeks-old Focal VM.

[Francois Thirioux (fthx)]

Well, there was a timeout issue last night, snapd 2.45pre3...
The only change I made in the day before was installing gnome-3-34 stable.

[Paul White (paulw2u)]

First report of timeout since April 29:

May 14 21:28:54 n1644 systemd[1]: Stopping Snap Daemon...
May 14 21:28:54 n1644 snapd[979]: main.go:155: Exiting on terminated signal.
May 14 21:29:19 n1644 snapd[979]: daemon.go:583: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
May 14 21:30:24 n1644 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
May 14 21:30:24 n1644 systemd[1]: snapd.service: Killing process 979 (snapd) with signal SIGKILL.
May 14 21:30:24 n1644 systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
May 14 21:30:24 n1644 systemd[1]: snapd.service: Failed with result 'timeout'.
May 14 21:30:24 n1644 systemd[1]: Stopped Snap Daemon.
May 14 21:30:24 n1644 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
May 14 21:30:24 n1644 systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (systemd-update-utmp.service has 'stop' job queued, but 'start' is included in transaction).

paul@n1644:~$ snap changes
ID Status Spawn Ready Summary
630 Done yesterday at 15:18 BST yesterday at 15:18 BST Refresh all snaps: no updates
631 Done yesterday at 21:05 BST yesterday at 21:05 BST Refresh all snaps: no updates
632 Done today at 10:04 BST today at 10:04 BST Connect chromium:password-manager-service to core:password-manager-service

[Gaurish Korpal (gkorpal)]

I did a fresh install of Ubuntu 20.04 a couple of days ago, however today I started getting delayed shutdown due to this bug. I even tried re-installing Ubuntu 20.04, but after the first system update itself the shutdown was delayed.

$ snap --version
snap 2.44.3+20.04
snapd 2.44.3+20.04
series 16
ubuntu 20.04
kernel 5.4.0-31-generic

$ snap list
Name Version Rev Tracking Publisher Notes
canonical-livepatch 9.5.5 95 latest/stable canonical✓ -
core 16-2.44.3 9066 latest/stable canonical✓ core
core18 20200311 1705 latest/stable canonical✓ base
gnome-3-34-1804 0+git.2c86692 24 latest/stable/… canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable/… canonical✓ -
snap-store 3.36.0-74-ga164ec9 433 latest/stable/… canonical✓ -
snapd 2.44.3 7264 latest/stable canonical✓ snapd

$ journalctl -e --no-pager -b -1 -u snapd
-- Logs begin at Sat 2020-05-23 14:29:06 MST, end at Sat 2020-05-23 14:54:55 MST. --
May 23 14:29:09 ideal-pc systemd[1]: Starting Snap Daemon...
May 23 14:29:09 ideal-pc snapd[651]: AppArmor status: apparmor is enabled and all features are available
May 23 14:29:09 ideal-pc snapd[651]: daemon.go:343: started snapd/2.44.3+20.04 (series 16; classic) ubuntu/20.04 (amd64) linux/5.4.0-31-generic.
May 23 14:29:09 ideal-pc snapd[651]: daemon.go:436: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
May 23 14:29:09 ideal-pc snapd[651]: helpers.go:105: error trying to compare the snap system key: system-key missing on disk
May 23 14:29:09 ideal-pc systemd[1]: Started Snap Daemon.
May 23 14:29:41 ideal-pc snapd[651]: daemon.go:539: gracefully waiting for running hooks
May 23 14:29:41 ideal-pc snapd[651]: daemon.go:541: done waiting for running hooks
May 23 14:29:43 ideal-pc systemd[1]: snapd.service: Succeeded.
May 23 14:29:43 ideal-pc systemd[1]: snapd.service: Scheduled restart job, restart counter is at 1.
May 23 14:29:43 ideal-pc systemd[1]: Stopped Snap Daemon.
May 23 14:29:43 ideal-pc systemd[1]: Starting Snap Daemon...
May 23 14:29:43 ideal-pc snapd[2412]: AppArmor status: apparmor is enabled and all features are available
May 23 14:29:43 ideal-pc snapd[2412]: patch.go:64: Patching system state level 6 to sublevel 1...
May 23 14:29:43 ideal-pc snapd[2412]: patch.go:64: Patching system state level 6 to sublevel 2...
May 23 14:29:43 ideal-pc snapd[2412]: patch.go:64: Patching system state level 6 to sublevel 3...
May 23 14:29:43 ideal-pc snapd[2412]: daemon.go:343: started snapd/2.44.3+20.04 (series 16; classic) ubuntu/20.04 (amd64) linux/5.4.0-31-generic.
May 23 14:29:43 ideal-pc snapd[2412]: daemon.go:436: adjusting startup timeout by 35s (pessimistic estimate of 30s plus 5s per snap)
May 23 14:29:43 ideal-pc systemd[1]: Started Snap Daemon.
May 23 14:30:31 ideal-pc snapd[2412]: api.go:985: Installing snap "canonical-livepatch" revision unset
May 23 14:34:27 ideal-pc systemd[1]: Stopping Snap Daemon...
May 23 14:34:27 ideal-pc snapd[2412]: main.go:155: Exiting on terminated signal.
May 23 14:34:5...

[Yanik (chescos)]

Having the same issue here on a fresh 20.04 installation.

[Paul White (paulw2u)]

Further to my comment #18 I haven't seen this issue for nearly two months now so unsubscribing but changing status back to 'Confirmed' as the information requested in comment #8 has been supplied and others have since also said that they are affected by this issue.

[Vincent LESCAUT (vincent-lescaut)]

Hi,
I'm facing the same issue with Ubuntu 18.04, at least to mention this annoying issue does not impact only Ubuntu 20 users.
Here is the output of journalctl -e --no-pager -b -1 -u snapd:
-- Logs begin at Mon 2019-04-08 02:59:33 CEST, end at Sat 2020-08-22 09:40:26 CEST. --
août 22 00:58:54 vincent-N750JV systemd[1]: Starting Snap Daemon...
août 22 00:58:55 vincent-N750JV snapd[1196]: AppArmor status: apparmor is enabled and all features are available
août 22 00:58:57 vincent-N750JV snapd[1196]: AppArmor status: apparmor is enabled and all features are available
août 22 00:58:57 vincent-N750JV snapd[1196]: daemon.go:343: started snapd/2.45.2 (series 16; classic) ubuntu/18.04 (amd64) linux/4.15.0-112-generic.
août 22 00:58:57 vincent-N750JV snapd[1196]: daemon.go:436: adjusting startup timeout by 1m25s (pessimistic estimate of 30s plus 5s per snap)
août 22 00:58:57 vincent-N750JV systemd[1]: Started Snap Daemon.
août 22 00:59:00 vincent-N750JV snapd[1196]: storehelpers.go:438: cannot refresh: snap has no updates available: "canonical-livepatch", "gnome-3-26-1604", "gnome-3-28-1804", "gnome-3-34-1804", "gnome-calculator", "gnome-characters", "gnome-logs", "gnome-system-monitor", "gtk-common-themes"
août 21 23:15:48 vincent-N750JV snapd[1196]: main.go:155: Exiting on terminated signal.
août 21 23:15:48 vincent-N750JV systemd[1]: Stopping Snap Daemon...
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: Killing process 1196 (snapd) with signal SIGKILL.
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: Failed with result 'timeout'.
août 21 23:17:18 vincent-N750JV systemd[1]: Stopped Snap Daemon.
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: Triggering OnFailure= dependencies.
août 21 23:17:18 vincent-N750JV systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction is destructive.

[Francois Thirioux (fthx)]

I still experience this bug in Focal (up to date). Happens at least 50% of shutdowns, delayed between 30s and 1m33s limit.

-- Logs begin at Fri 2020-03-06 07:41:08 CET, end at Sat 2020-08-22 10:02:36 CEST. --
août 21 20:59:44 portable-fthx systemd[1]: Starting Snap Daemon...
août 21 20:59:44 portable-fthx snapd[1021]: AppArmor status: apparmor is enabled and all features are available
août 21 20:59:45 portable-fthx snapd[1021]: AppArmor status: apparmor is enabled and all features are available
août 21 20:59:45 portable-fthx snapd[1021]: daemon.go:343: started snapd/2.45.3.1 (series 16; classic) ubuntu/20.04 (amd64) linux/5.4.0-44-generic.
août 21 20:59:45 portable-fthx snapd[1021]: daemon.go:436: adjusting startup timeout by 1m40s (pessimistic estimate of 30s plus 5s per snap)
août 21 20:59:45 portable-fthx systemd[1]: Started Snap Daemon.
août 21 20:59:45 portable-fthx snapd[1021]: autorefresh.go:390: Cannot prepare auto-refresh change: cannot refresh snap-declaration for "gtk2-common-themes": Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/QTTvBfEDSFw9OAOmdhHWdYh0BNNgz3BU?max-format=4: dial tcp: lookup api.snapcraft.io: no such host
août 21 20:59:45 portable-fthx snapd[1021]: stateengine.go:150: state ensure error: cannot refresh snap-declaration for "gtk2-common-themes": Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/.......?max-format=4: dial tcp: lookup api.snapcraft.io: no such host
août 21 22:53:05 portable-fthx snapd[1021]: main.go:155: Exiting on terminated signal.
août 21 22:53:05 portable-fthx systemd[1]: Stopping Snap Daemon...
août 21 22:53:30 portable-fthx snapd[1021]: daemon.go:586: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
août 21 22:53:30 portable-fthx systemd[1]: snapd.service: Succeeded.
août 21 22:53:30 portable-fthx systemd[1]: Stopped Snap Daemon.

[Eugene Lazutkin (eugene-lazutkin-gmail)]

I have this bug in 20.10 (upgraded from 20.04). On shutdown it always waits for 90 seconds, then it times out and the shutdown proceeds normally. I have the same log as in:

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1873550/comments/3

[rud (jazco)]

It happens at a clean, fesh, new install (wiped disk) of Ubuntu 20.04 Budgie without any snap packages manually installed after first boot, when I want to restart because updates were installed.

Do we actually need Snap Daemon if you avoid installing any Snap packages? I never go for the Snap version as they usually start slower and can have issues integrating flawlessly in your desktop distribution.

[Giovanni Panozzo (giox069)]

Happened now on a fresh install od ubuntu desktop 20.04.1.
It does not happen at every shutdown. It happened only at the 1st shutdown that I did after 4 minutes of uptime. Could be snapd working for updating/upgrading something?

[Vince Samuels (lispy-sardine)]

Nov 28 18:54:55 hostname systemd[1]: Started Snap Daemon.
Nov 28 18:55:06 hostname snapd[770]: main.go:155: Exiting on terminated signal.
Nov 28 18:55:06 hostname systemd[1]: Stopping Snap Daemon...
Nov 28 18:55:19 hostname snapd[770]: autorefresh.go:398: Cannot prepare auto-refresh change due to a permanent network error: persistent network error: Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/xxx/xxx?max-format=4: dial tcp: lookup api.snapcraft.io: Temporary failure in name resolution
Nov 28 18:56:04 hostname snapd[770]: stateengine.go:150: state ensure error: persistent network error: Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/xxx/xxx?max-format=4: dial tcp: lookup api.snapcraft.io: Temporary failure in name resolution
Nov 28 18:56:04 hostname systemd[1]: snapd.service: Succeeded.
Nov 28 18:56:04 hostname systemd[1]: Stopped Snap Daemon.

For anyone looking for a workaround:

$ sudo systemctl edit snapd.service

If empty, only add the following:

[Service]
TimeoutSec=15

I guess the value of TimeoutSec depends on how much you value the data integrity of snaps/containers that you run. I prefer not having snaps at all. I only still have it for LXD because it stopped doing apt packages. Anyway the LXC containers I run are not important, so 3 seconds is more than enough for me personally.

[Francois Thirioux (fthx)]

I realize that I do not experience this bug anymore. Any other feedback ?

$ snap --version
snap 2.48.1
snapd 2.48.1
series 16
ubuntu 20.04
kernel 5.8.0-34-generic

[Saurabh Joshi (joshio)]

I still experience this bug:

$ snap --version
snap 2.48.2
snapd 2.48.2
series 16
ubuntu 20.04
kernel 5.4.0-64-generic

I looked at the service logs for snapd and everytime I have experienced this issue it was due to this:
snapd[986]: autorefresh.go:467: Cannot prepare auto-refresh change due to a permanent network error: persistent network error: Post https://api.snapcraft.io/v2/snaps/refr>

The network error gave me a clue as to why this might be happening. I have another unrelated issue where sometimes the network card in my computer is not recognized unless I reboot. So whenever I reboot my computer to fix my network card issue I experience this bug.

[andschuster (andreas-schuster2)]

This bug affects me, too, on Kubuntu 20.10:

snap 2.48.3+20.10
snapd 2.48.3+20.10
series 16
ubuntu 20.10
kernel 5.8.0-43-generic

[Francois Thirioux (fthx)]

Well, I do still experience this bug. I was too optimistic, because it happens less often than some time ago.

snapd 2.48.3 in Focal

[Paul White (paulw2u)]

I have not seen this issue in my Focal installation for over a year now. But the isse seems to be present in my 3-day old Impish installation.

Jul 05 18:21:31 n1687 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Jul 05 18:21:31 n1687 systemd[1]: snapd.service: Killing process 773 (snapd) with signal SIGKILL.
Jul 05 18:21:31 n1687 systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Jul 05 18:21:31 n1687 systemd[1]: snapd.service: Failed with result 'timeout'.
Jul 05 18:21:31 n1687 systemd[1]: Stopped Snap Daemon.
Jul 05 18:21:31 n1687 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
Jul 05 18:21:31 n1687 systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (umount.target has 'start' job queued, but 'stop' is included in transaction).

snap --version
snap 2.51.1+21.10
snapd 2.51.1+21.10
series 16
ubuntu 21.10
kernel 5.11.0-20-generic

[Vinsent Levitsky (vinsent2002)]

This bug affects me, on Ubuntu 20.04.03 LTS.

>snap --version
snap 2.51.4
snapd 2.51.4
series 16
ubuntu 20.04
kernel 5.11.0-27-generic

>snap list
Name Version Rev Tracking Publisher Notes
core 16-2.51.4 11606 latest/stable canonical✓ core
core18 20210722 2128 latest/stable canonical✓ base
gnome-3-28-1804 3.28.0-19-g98f9e67.98f9e67 161 latest/stable canonical✓ -
gnome-3-34-1804 0+git.3556cb3 72 latest/stable/… canonical✓ -
gtk-common-themes 0.1-52-gb92ac40 1515 latest/stable/… canonical✓ -
skype 8.75.0.140 183 latest/stable skype✓ -
snapd 2.51.4 12883 latest/stable canonical✓ snapd

[vladimir2k9 (vladimir2k9)]

This bug affects me, on Ubuntu 21.10

$ snap --version
snap 2.53+21.10ubuntu1
snapd 2.53+21.10ubuntu1
series 16
ubuntu 21.10
kernel 5.13.0-19-generic
$ snap list
Название Версия Правка Канал Издатель Примечание
bare 1.0 5 latest/stable canonical✓ base
chromium 94.0.4606.81 1781 latest/stable canonical✓ -
core18 20210722 2128 latest/stable canonical✓ base
core20 20210928 1169 latest/stable canonical✓ base
gnome-3-28-1804 3.28.0-19-g98f9e67.98f9e67 161 latest/stable canonical✓ -
gnome-3-34-1804 0+git.3556cb3 72 latest/stable/… canonical✓ -
gnome-3-38-2004 0+git.6ba6040 76 latest/stable canonical✓ -
gtk-common-themes 0.1-59-g7bca6ae 1519 latest/stable/… canonical✓ -
snap-store 3.38.0-66-gbd5b8f7 557 latest/stable/… canonical✓ -
snapd 2.52 13270 latest/stable canonical✓ snapd

[Paul White (paulw2u)]

Further to my comment #32:

After a recent re-installation of 'impish' in late July (for reasons not relevant here) using the same hardware and ISO image, and many reboots later I haven't seen this delay before shutting down or rebooting at all.

[Alberto Mardegan (mardy)]

I believe that this is the same issue as #1946656, which will be fixed in snapd 2.53:

https://github.com/snapcore/snapd/commit/da1caa8b12c0f839320f29012b4565d1f702eb42

[bitterhalt (bitterhalt)]

I installed Ubuntu 21.10 a week a go and I got this massive delay with every reboot because of snap deamon hang.

journalctl -e --no-pager -b -1 -u snapd
-- Journal begins at Sat 2021-12-25 12:56:07 EET, ends at Sun 2021-12-26 01:11:31 EET. --
joulu 25 23:24:24 bazz-ser systemd[1]: Starting Snap Daemon...
joulu 25 23:24:24 bazz-ser snapd[949]: AppArmor status: apparmor is enabled and all features are available
joulu 25 23:24:24 bazz-ser snapd[949]: daemon.go:242: started snapd/2.53+21.10ubuntu1 (series 16; classic) ubuntu/21.10 (amd64) linux/5.13.0-22-generic.
joulu 25 23:24:24 bazz-ser snapd[949]: daemon.go:335: adjusting startup timeout by 1m15s (pessimistic estimate of 30s plus 5s per snap)
joulu 25 23:24:24 bazz-ser systemd[1]: Started Snap Daemon.
joulu 25 23:26:47 bazz-ser snapd[949]: storehelpers.go:710: cannot refresh: snap has no updates available: "bare", "btop", "core", "core18", "core20", "gnome-3-28-1804", "gnome-3-38-2004", "gtk-common-themes", "snap-store"
joulu 25 23:26:47 bazz-ser snapd[949]: storehelpers.go:710: cannot refresh: snap has no updates available: "bare", "btop", "core", "core18", "core20", "gnome-3-28-1804", "gnome-3-38-2004", "gtk-common-themes", "snap-store"
joulu 25 23:26:50 bazz-ser snapd[949]: storehelpers.go:710: cannot refresh: snap has no updates available: "bare", "btop", "core", "core18", "core20", "gnome-3-28-1804", "gnome-3-38-2004", "gtk-common-themes", "snap-store"
joulu 25 23:40:28 bazz-ser snapd[949]: api_snaps.go:307: Installing snap "brave" revision unset
joulu 25 23:40:40 bazz-ser snapd[949]: api_snaps.go:307: Installing snap "brave" revision unset
joulu 25 23:40:49 bazz-ser snapd[949]: api_snaps.go:307: Installing snap "brave" revision unset
joulu 26 01:06:42 bazz-ser snapd[949]: storehelpers.go:710: cannot refresh: snap has no updates available: "bare", "brave", "btop", "core", "core18", "core20", "gnome-3-28-1804", "gnome-3-38-2004", "gtk-common-themes", "snap-store"
joulu 26 01:06:46 bazz-ser systemd[1]: Stopping Snap Daemon...
joulu 26 01:06:46 bazz-ser snapd[949]: main.go:155: Exiting on terminated signal.
joulu 26 01:07:11 bazz-ser snapd[949]: daemon.go:544: WARNING: cannot gracefully shut down in-flight snapd API activity within: 25s
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Killing process 949 (snapd) with signal SIGKILL.
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Failed with result 'timeout'.
joulu 26 01:08:16 bazz-ser systemd[1]: Stopped Snap Daemon.
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Triggering OnFailure= dependencies.
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Failed to enqueue OnFailure= job, ignoring: Transaction for snapd.failure.service/start is destructive (cryptsetup.target has 'stop' job queued, but 'start' is included in transaction).
joulu 26 01:08:16 bazz-ser systemd[1]: snapd.service: Consumed 8.005s CPU time.
bazz@bazz-ser:~$

[Ian Johnson (anonymouse67)]

Hi @bitterhalt, can you try installing the snapd snap via `snap install snapd` and then see if your system is still affected? As Alberto mentioned, we do expect this to be fixed now with the aforementioned commit.