As I understand it we now defer snapd refreshing snaps until some hours after a system has booted.
We do not appear to defer snapd refreshes after waking from suspend.
I tend to leave my laptop on and just suspend it by shutting the lid. It can go for a day or more without being opened. I have a lot (80+) of snaps installed, some of which are from the non-stable channels. So I get a fair number of updates on a frequent basis.
When I wake my laptop snapd will start refreshing all those snaps which helps to grind the machine to a halt for the first few minutes after waking. Snapd refreshing is contending with applications which are updating / sending notifications and unattended-upgrades.
Most recently wanted to wake my laptop up to do a “quick bit of work” but was left waiting while snapd refreshed 7 applications (including core). I managed to get to a terminal and spotted snapd at the top of the list. This seems sub-optimal and inconsistent with our boot behaviour. Can we defer snapd refresh until some time after wake from suspend please?
I had this happen again today. My (16GB / i7 / SSD) laptop is completely unusable for minutes after waking from suspend as it’s doing all the snap refresh updates. Today there were only 8, but that’s because I used my laptop yesterday. It can be way more, and thus more of a grind.
Hard to know if that will fix it without testing. It’s not so much the network download which pegs my laptop. I believe it’s all the disk IO when copying files about. It’s hard to know because the laptop is pegged and unusable during those operations.
Instead of just the delay, it might be useful to “rate limit” the number of snaps that get updated every X amount of minutes.
Say it wakes up, notices that 25 snaps need to be updated. It’ll update 5 snaps every 10 minutes, spanning 50 minutes, giving priority to any core snaps.
Since we now have the refresh.hoild functionality, I’m playing with this little service locally:
[Unit]
Description=Hold snapd refresh when resuming from sleep
After=systemd-suspend.service systemd-hybrid-sleep.service systemd-hibernate.service
[Service]
Type=simple
ExecStart=/bin/sh -c '/usr/bin/snap set system refresh.hold=$(date --iso-8601=seconds -d "10 minutes")'
[Install]
WantedBy=sleep.target
The service should be run as part of sleep.target, but it will only be started after systemd helper services complete. The helpers implement the actual suspend/hibernate, and exit when the system wakes up, so snapd hold service should run right after.
I’m testing this locally on Arch, with systemd 240. So far, across a couple of suspend/wakup cycles, the refresh-hold helper was being correctly started after the the system woke up and snapd configuration was updated accordingly.
Would you mind testing this for a while in your system? Write the unit definition to /etc/systemd/system/snapd.hold-refresh-after-resume.service and then execute:
Once the system resumes, there should be a log in the journal from when systemd started the service. The configuration of snapd should also be updated:
$ snap get system refresh
Key Value
refresh.hold 2019-01-17T13:49:07+01:00 <--- this should be roughly
~now + 10 minutes
