no information about snap updates

[Laryllan]

As far as I know, updates of snap packages are done automatically.

Unfortunately there is no transparent way of knowing when updates took place.
Snapd reports the most recent updates using the 'snap changes' command, but the output does only show updates since the start of snapd.

I expected that there is an refresh log available, similar to the apt update log in /var/log/apt...

Ubuntu 17.04
snapd 2.25+17.04

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mark Shuttleworth (sabdfl)]

How about a MOTD entry like this:

 * 12 snaps updated in last 14 days, see 'snap updates'

... with a new 'updates' or 'list-updates' command that shows only a log
of updates?

Mark

[Ads20000 (ads20000)]

I think Mark the point is that it would be nice to have a full list of updates stored somewhere so that one can see exactly what happened to the snaps installed or previously installed over time, so if something goes wrong (but the bug isn't noticed for a while) then one can try and trace back to the exact revision combination of snap (+ content snap) + base snap that broke things.

[Ads20000 (ads20000)]

Maybe this exists since this bug was filed, in which case, would be nice to have an explanation of where that information is! :)

[Laryllan (laryllan)]

Are the any news about the issue?

[John Lenton (chipaca)]

Today, snap updates (and any other changes under snapd's control) are visible in 'snap changes' for a few days.

After that they are cleaned up, to stop snapd from using up too many system resources.

We are aware that people want to be able to keep them around for longer, but have not gotten around to implementing that yet.

[David Torrey (dotj)]

Pinging to get this additional attention. Based on casework and personal experience, the ability to conclusively see a longer history of snap changes would be helpful in diagnosing latent symptoms, whether they occur late, get noticed late, or the triage happens late. This is especially important as more and more services are delivered as snaps (i.e. kubelet), where an unplanned restart can be an undesired surprise.

`snap changes` seems to be an ideal mechanism for this, where at least the timestamps provided would point us to the proper section of other possible log sources.