Snap refresh after system time is corrected

device
1

I build an appliance image for a Raspberry Pi-based device without keyboard input, based on a slightly customized Ubuntu Core 18 gadget. The appliance does not have internet access until the user plugs in LAN / provides WiFi credentials via a hotspot setup. My gadget configures snapd with a refresh timer of 03:00-05:00/3 – i.e. max. three times between 03-05am. However, snapd auto-refreshes snaps outside that window in the following scenario:

  • image is used on Raspberry Pi devices → no real-time clock
  • image is built with and outdated version of a snap → would be refreshed by snapd
  • image is pre-booted (see below for details) without internet access → no NTP / time sync opportunity
  • during setup, I set the system time from the user’s browser time → system time jumps from whenever the image was created to the current timestamp

Is it expected behavior for snapd to refresh immediately, even if the current time is not in the 3-5am window? I guess it comes down to this sudden clock jump and Epoch timestamps, but want to confirm this hunch.

Follow-up: Would this still occur if the image is not pre-booted, but otherwise identical (outdated snap, system clock off by days/weeks until provided during setup)

Reasons for pre-booting

At the moment, I run the first boot on one of our Pis, check if everything went ok and then dd the final image from that installation. I know that pre-booting images is not supported and may have all sorts of side effects. Main reason is that our average user base would pull the plug during the initialization because it

ping @ijohnson @ogra @sil2100

2

It seems that you are unfortunately running into https://bugs.launchpad.net/snapd/+bug/1856063 which we do intend to fix.

However, in addition to that bug, we do not handle sudden clock jumps very well in the refresh code, so if snapd had in fact booted and thought it was 1970 when it checked for refreshes and there was none available, when the system time jumps forward to 2021, it will think the last refresh time was 51 years ago, which is outside of the max time that you can defer a refresh and it will perform the auto-refresh anyways, so even if that bug is fixed you may find some issues around auto-refreshes happening shortly after sudden time jumps. The only exception would be if time jumps forward, but still within the window of the max time that you can defer refreshes (60 days IIRC).

It probably would yes.

3

We eventually want to enable swap as a snap set system swap=200M kind of thing that you would be able to configure from your gadget.yaml, but it requires a bit of design and so we haven’t implemented it yet.

1 Like
4

Thanks for clarifying snaps behavior here! Makes sense and a sudden clock jump certainly isn’t normal system behavior. I’ve implemented a “system is updating” message for my gadget image so that the user at least knows what’s going on. As core snap refreshes will cause a reboot, I guess I’ll build a fresh image ASAP after a core release for now.

I’ll write up a new post to discuss possible “initial boot user feedback” ideas later; this thread was mainly to confirm that I didn’t overlook something obvious :grinning_face_with_smiling_eyes:

1 Like
5

@tobias it took a while, but in snapd 2.52 (or on the edge channel in a few hours) you can now do snap set system swap.size=200M, including from the gadget.yaml like so:

defaults:
  system:
    swap:
      size: 200M

Hope this helps

2 Likes