Live images should be able to turn off Snap updates

[Jonathan Riddell]

There should be a way to turn off Snap updates while allowing Snaps to still run. When Live CD images start having Snaps installed by default they won't want the packages to be updated while in live mode but they will want applications to be runable.

Probably there should be a setting for this and Casper should be easily able to set that setting.

[Colin Watson (cjwatson)]

snapcraft handles building; this seems like more of a snapd thing.

But is anything actually needed in snapd? Couldn't casper just do "systemctl disable snapd.refresh.service"?

[Zygmunt Krynicki (zyga)]

I think the only way to do that today is to disable the service and the (fallback) refresh timer.

Is there a technical problem with the update or just a preference to not do this?

[Will Cooke (willcooke)]

I think this is already being addressed, but for completeness, the issue is that the snap updates and then exhausts all available RAM causing the live session to crash.

[Michael Hudson-Doyle (mwhudson)]

For the record, the plan for the live server installer is to run “snap set core refresh.hold=$(date --date=now+60days --iso-8601=seconds)” fairly early on. If people leave their live sessions going for 60 days, so be it…

[Iain Lane (laney)]

On Wed, Mar 21, 2018 at 08:13:23AM -0000, Michael Hudson-Doyle wrote:
> For the record, the plan for the live server installer is to run “snap
> set core refresh.hold=$(date --date=now+60days --iso-8601=seconds)”
> fairly early on. If people leave their live sessions going for 60 days,
> so be it…

The installer itself will run that?

I see from here

  https://forum.snapcraft.io/t/development-sprint-march-5th-2018/4345/11

"At the refresh attempt, if inside a hold window, skip it as long as it
doesn’t go beyond the maximum number of days (60 days right now)

Must warn if requested hold cannot be respected due to maximum period"

It doesn't say what the maximum number of days is since - do you know?
If it it since the last refresh, is that the date that the image was
created? If so, what happens if your image is more than 60 days old? It
sounds to me like this spec won't let you hold refresh in that case.
Have you checked this?

Probably easier if I just comment on that thread:

  https://forum.snapcraft.io/t/development-sprint-march-5th-2018/4345/35

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Michael Hudson-Doyle (mwhudson)]

On 21 March 2018 at 22:23, Iain Lane <email address hidden> wrote:

> On Wed, Mar 21, 2018 at 08:13:23AM -0000, Michael Hudson-Doyle wrote:
> > For the record, the plan for the live server installer is to run “snap
> > set core refresh.hold=$(date --date=now+60days --iso-8601=seconds)”
> > fairly early on. If people leave their live sessions going for 60 days,
> > so be it…
>
> The installer itself will run that?
>

Well
https://code.launchpad.net/~mwhudson/livecd-rootfs/live-server-set-refresh.hold/+merge/341801
is my not very elegant proposal so far

> I see from here
>
> https://forum.snapcraft.io/t/development-sprint-march-5th-2018/4345/11
>
> "At the refresh attempt, if inside a hold window, skip it as long as it
> doesn’t go beyond the maximum number of days (60 days right now)
>
> Must warn if requested hold cannot be respected due to maximum period"
>
> It doesn't say what the maximum number of days is since - do you know?
> If it it since the last refresh, is that the date that the image was
> created? If so, what happens if your image is more than 60 days old? It
> sounds to me like this spec won't let you hold refresh in that case.
> Have you checked this?
>

I assume that it's 60 days since the seeding process (how would snapd know
how old the image is?). But I haven't checked.

>
> Probably easier if I just comment on that thread:
>
> https://forum.snapcraft.io/t/development-sprint-march-5th-2018/4345/35
>
> Cheers,
>
> --
> Iain Lane [ <email address hidden> ]
> Debian Developer [ <email address hidden> ]
> Ubuntu Developer [ <email address hidden> ]
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1723094
>
> Title:
> Live images should be able to turn off Snap updates
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapd/+bug/1723094/+subscriptions
>

[Iain Lane (laney)]

On Wed, Mar 21, 2018 at 09:59:24AM -0000, Michael Hudson-Doyle wrote:
> > It doesn't say what the maximum number of days is since - do you know?
> > If it it since the last refresh, is that the date that the image was
> > created? If so, what happens if your image is more than 60 days old? It
> > sounds to me like this spec won't let you hold refresh in that case.
> > Have you checked this?
> >
>
> I assume that it's 60 days since the seeding process (how would snapd know
> how old the image is?). But I haven't checked.

Like (I'm making this up) if the `snap download' that we do records the
date, or if the core snap that we seed contains a published date and
this is considered the last refresh date if no explicit refresh has
happened yet.

It's a problem we were concerned about especially for LTS releases where
the ISOs people download might be quite old.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Jean-Baptiste Lallement (jibel)]

This patch adds a casper script to inject a systemd unit that sets refresh.hold to 60d in the future.

[Samuele Pedroni (pedronis)]

in a properly working snapd 2.32 60 days are computed from seed-time, which is when the snaps are installed at first boot (there are fallbacks based on other things but those are for corner cases, or preexisting installations)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "casper_1.391.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Jean-Baptiste Lallement (jibel)]

Updated to inject the service file in /etc instead of /lib

[Iain Lane (laney)]

thanks, I'm testing and will sponsor

[Jean-Baptiste Lallement (jibel)]

Thanks. For info I tested with a 3 weeks old ISO with out of date preinstalled snap packages on which I installed snapd 2.32 and casper with this patch and I verified that refresh.hold is set to 60d in the future and that no snap package is refreshed.

[Iain Lane (laney)]

I've uploaded, thanks for the contribution. I made a couple of changes as detailed in the changelog. After testing - it's quite irritating to test casper-bottom changes! - it still worked for me, but feel free to check yourself.

[Launchpad Janitor (janitor)]

This bug was fixed in the package casper - 1.391

---------------
casper (1.391) bionic; urgency=medium

  [ Jean-Baptiste Lallement ]
  * scripts/casper-bottom/55disable_snap_refresh:
    - Set refresh timer of snapd to 60 days on live session (LP: #1723094)

  [ Iain Lane ]
  * Modify the script a bit
    - Install in /run as a transient directory
    - Be WantedBy snapd.service, instead of Requires snapd.service & WantedBy
      multi-user.target, and update the symlink to match. It makes sense for
      us to order ourself to start right after snapd does.

 -- Jean-Baptiste Lallement <email address hidden> Thu, 22 Mar 2018 09:49:54 +0100