snap set refresh.hold immediately triggers a refresh when set

[Ian Johnson]

When launching a fresh multipass Ubuntu Core VM for a demo, it's desirable to turn off refreshes so that your demo doesn't get interrupted by a refresh during the demo. However the documented way to do this, by setting refresh.hold, actually seems to trigger a refresh!

See:

$ multipass launch core
Launched: achieving-stork
$ multipass shell achieving-stork
Welcome to Ubuntu Core 16 (GNU/Linux 4.4.0-157-generic x86_64)
 * Ubuntu Core: https://www.ubuntu.com/core
 * Community: https://forum.snapcraft.io
 * Snaps: https://snapcraft.io

This Ubuntu Core machine is a tiny, transactional edition of Ubuntu,
designed for appliances, firmware and fixed-function VMs.

If all the software you care about is available as snaps, you are in
the right place. If not, you will be more comfortable with classic
deb-based Ubuntu Server or Desktop, where you can mix snaps with
traditional debs. It's a brave new world here in Ubuntu Core!

Please see 'snap --help' for app installation and updates.
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@achieving-stork:~$ snap changes
ID Status Spawn Ready Summary
1 Done today at 15:29 UTC today at 15:30 UTC Initialize system state
2 Done today at 15:30 UTC today at 15:30 UTC Initialize device

ubuntu@achieving-stork:~$ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.39.3 7270 stable canonical✓ core
pc 16.04-0.10 33 stable canonical✓ gadget
pc-kernel 4.4.0-157.185 258 stable canonical✓ kernel
ubuntu@achieving-stork:~$ sudo snap set system refresh.hold="$(date --date=tomorrow +%Y-%m-%dT%H:%M:%S%:z)"
ubuntu@achieving-stork:~$ snap changes
ID Status Spawn Ready Summary
1 Done today at 15:29 UTC today at 15:30 UTC Initialize system state
2 Done today at 15:30 UTC today at 15:30 UTC Initialize device
3 Done today at 15:30 UTC today at 15:30 UTC Change configuration of "core" snap
4 Doing today at 15:30 UTC - Auto-refresh snaps "core", "pc-kernel"
```

The same thing happens on UC18 as well, albeit with a different set of snaps obviously, core18, snapd and pc-kernel.

[Maciej Borzecki (maciek-borzecki)]

Looks like it's a specific scenario for the core devices. I believe this happens:
- system seeding completes
- there's no previous refresh, so it falls back to the mod time of either the core snap or the snapd executable
- ensure loop runs every 5 minutes, so if that happens first the system will auto refresh
- calling `snap set system refresh.hold=..` triggers EnsureBefore(0), so it actually speeds up the auto refresh

In comparison, in cloud images, snapd automatically sets up refresh.hold=now+2h after seeding completes. Perhaps it's something we should do for newly seeded core images too. Some input from Mvo or Samuele would be useful here.

[Samuele Pedroni (pedronis)]

Some remarks

* it's by design that core images try to refresh as soon possible (the main scenario is a device booting out of a shelf)

* so we cannot really make them wait 2h

* multipass images are very easy to boot and have different usage cases than real devices

we need to think ways to address the latter without degrading the former

[Samuele Pedroni (pedronis)]

* multipass images are very easy to boot and have different usage cases than real devices

also they should get updated regularly (?) which would make fast refresh less relevant

[Ian Johnson (anonymouse67)]

I inquired about multipass images specifically, and they use the stable channel images, which are only updated once per each dot-release, so they will almost always be out-of-date, until work to automate building those images can be scheduled.

[Dimitri John Ledkov (xnox)]

so core devices try to refresh as soon as possible, which interferes with console-conf.

1) console-conf brings up network
2) snapd tries to refresh
3) consoleconf tries to take ownership of the device

Depending on how fast 2 or 3 are, one might be able to take ownership of the device or refresh succeeds.

[Ian Johnson (anonymouse67)]

Well I actually can't reproduce this exactly anymore because it seems that snapd schedules the refresh to happen before I can get a shell to the system on multipass,

$ sudo snap debug state /var/lib/snapd/state.json --abs-time
ID Status Spawn Ready Label Summary
1 Done 2020-09-21T19:11:45Z 2020-09-21T19:11:53Z seed Initialize system state
2 Done 2020-09-21T19:11:55Z 2020-09-21T19:11:58Z become-operational Initialize device
3 Doing 2020-09-21T19:12:00Z 0001-01-01T00:00:00Z auto-refresh Auto-refresh snaps "snapd", "pc-kernel"
4 Done 2020-09-21T19:12:01Z 2020-09-21T19:12:01Z configure-snap Change configuration of "core" snap

and this was with a scripted run of calling snap set, so I'm not sure I could do it much faster unless I deliberately slowed down the VM I suppose.

[Ian Johnson (anonymouse67)]

Setting this to high in case console-conf wants to start delaying snap refreshes on first boot, since this bug will block that.

[Tony Espy (awe)]

Note this also occurs if you try delay the refresh by setting refresh.timer to a value which would result in the next refresh occurring sometime in the future.