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?
Amy chance someone can take a look at this? @mvo maybe?
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.
@niemeyer is this something we can please fix?
@popey if instead of delaying the update, it was rate limited, would that work for you?
alternatively: I wonder if there’s a straightforward way for systemd to stop snapd over suspend.
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.
What do you mean you’re not psychic?!
We can add a
Conflcits: sleep.target to
snapd.service, but I’m not sure how to bring it back up on resume.
We could also add a thing (something something
systemd-sleep.conf something) so that we do a refresh hold on suspend, maybe that’s easier.
Just had it again with 10 snaps refreshing on wake from suspend. It made video calls impossible until they’d finished
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.
Restart a snap background service on resume from suspend triggered some interest in addressing the problem of delaying snapd refresh on wakeup.
Since we now have the
refresh.hoild functionality, I’m playing with this little service locally:
Description=Hold snapd refresh when resuming from sleep
After=systemd-suspend.service systemd-hybrid-sleep.service systemd-hibernate.service
ExecStart=/bin/sh -c '/usr/bin/snap set system refresh.hold=$(date --iso-8601=seconds -d "10 minutes")'
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:
$ systemctl daemon-reload && \
systemctl enable snapd.hold-refresh-after-resume.service
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
refresh.hold 2019-01-17T13:49:07+01:00 <--- this should be roughly
~now + 10 minutes
Thanks @mborzecki - I’ve set that on my laptop and sure enough
refresh.hold is 10 mins from now (after waking). Thanks.
It’s 7 days into the field test. Have you noticed any issues so far?
Nope. I’ve used my laptop with suspend a fair amount, and it’s certainly not felt bogged down when waking from suspend as it previously did. Thanks!
Opened a PR to snapd so that it doesn’t get lost: https://github.com/snapcore/snapd/pull/6438