Imagine the following scenario: You’re a videographer, hired to produce a nice video of a wedding. You’re at the reception, and you want some aerial shots, so you break out your fancy snap-based UAV. You take off and start flying around getting several different angles, and all of a sudden your drone falls out of the sky and is destroyed.
What happened? An automatic update. Are there any plans to account for such a use-case? Ideally a snap could simply state itself to be in use and unable to update at that time. Thoughts?
Yes, this is definitely in the roadmap. We want to support both the user and any snap to report that they don’t want any automated disruption for up to N hours. We’ll cap that to a maximum number of hours, but no less than 24h I think.
A less critical scenario maybe more of a bug causing it. But when you are running a desktop snap, and it auto updates underneath you. It runs a risk of messing things up, especially if touching common folders. If it could download the new revision and signal the running snap that a new version is available. Let the snap then defer because its in use. We could then handle it in a graceful way and show something in the UI asking them to let us restart so they get newest version.
Understandably not all apps would integrate this far…
We would find this very useful to have today, we are currently blocking auto update on the gateway to prevent it able to access the API and update when the application can’t be updated. However to be able to control this on the app in a more elegant way would be much better.
I have this exact problem with the Chromium snap. It auto-updates on the background and I don’t get any sort of notification (am I missing something? I run i3wm on ubuntu, so I don’t exactly have all the standard stuff running).
This has caused me to lose tabs, even with an extension such as Session Buddy, because it can’t write its settings - probably due to app armor rules changing based on the new snap directories.
I was not sure this was really caused by a snap refresh, as previous I noticed this either after the laptop ran out of battery while suspended or after a crash - in both situations Chromium had been running for a few days and I noticed the snap had been refreshed, but there was some chance this could be due to unexpected reboot. Still, this never happened when using it from a deb install, even on unexpected reboots. Also, Chromium did exhibit some weird behavior like blank/black windows from time to time with no indication on the logs that I saw to give a clue about what was going on - except that there was a refresh sometime/days earlier.
Yesterday there was another Chromium update and today I got the blank windows (I usually have multiple tabs and windows up, as well as at least 2 profiles open). Killing a few chromium processes didn’t help and I had to kill the main process to get rid of it. Restarting it led me to a restore that missed a whole day of changes (closed tab/windows were open again and new ones lost), even with the Session Buddy extension that saves state on every tab/window change.
IMHO this is a main downside of using a snap. I would expect that either I get a notification about the update (and have a way to hold it) so I can close Chromium and guarantee that the state is saved or have a way that any state is still allowed to be written after the refresh is done.
BTW, I’m guessing that both Chromium and the extension are unable to write their state after the refresh based on the fact that downloads start failing as well.
Please let me know if this is actually a bug on the way the Chromium snap handles refreshes instead of a general problem with snaps so I can report that to them.
This problem is partly an implementation issue that is being fixed. @zyga-snapd has that at the top (or close) of his list. We believe with very minor changes we can fix this issue altogether so that chrome can be updated in the background without it causing any similar issues. We’ll try to land the fix in time for 2.33.
Meanwhile is there anything I can run manually to allow the running chromium process to access the old directory so when I close it it will be able to write state?
Chromium was refreshed from 266 to 274 back in 2018-04-03T11:21:31-03:00 and since I didn’t noticed that right away I still have 266 running. dmesg shows a lot of denied access to the config directory:
[216657.271824] audit: type=1400 audit(1523034491.823:133728): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromium” name="/home/tdaitx/snap/chromium/266/.config/chromium/Default/Cookies-journal" pid=17477 comm=“TaskSchedulerBa” requested_mask=“wc” denied_mask=“wc” fsuid=1000 ouid=1000
UPDATE:
As a reference for anyone else running into this, I “fixed” the issue by editing chromium’s profile:
--- /var/lib/snapd/apparmor/profiles/snap.chromium.chromium.orig 2018-04-06 14:38:03.993227496 -0300
+++ /var/lib/snapd/apparmor/profiles/snap.chromium.chromium 2018-04-06 14:33:21.461700026 -0300
@@ -335,6 +335,7 @@
owner @{HOME}/snap/@{SNAP_NAME}/** mrkix,
# Writable home area for this version.
+ owner @{HOME}/snap/@{SNAP_NAME}/266/** wl,
owner @{HOME}/snap/@{SNAP_NAME}/@{SNAP_REVISION}/** wl,
owner @{HOME}/snap/@{SNAP_NAME}/common/** wl,
@@ -343,6 +344,7 @@
/var/snap/@{SNAP_NAME}/** mrkix,
# Writable system area only for this version
+ /var/snap/@{SNAP_NAME}/266/** wl,
/var/snap/@{SNAP_NAME}/@{SNAP_REVISION}/** wl,
/var/snap/@{SNAP_NAME}/common/** wl,
Please not that this is just a hack in order to be able to close the browser without losing state.
Before restarting chromium I also replaced the 274 directory with 266 (with a backup of each just in case). After the restart it seems like chromium’s apparmor profile was re-generated and my changes to it were gone.
Please, do not try this if you don’t understand what I am talking about.
By way of a real world example. I have been hit by this a number of times and it’s starting to really get on my nerves, and waste my working time.
While doing snapcraft cleanbuild which uses ephemeral lxd containers, the lxd snap will update and destroy my work mid-way through a build. On this occasion it was a small snap and fell over early on in the lifecycle, but it can strike at more irritating stages, like just as it’s priming.
Unpacking gcc (4:5.3.1-1ubuntu1) ...
Selecting previously unselected package libstdc++-5-dev:amd64.
Preparing to unpack .../libstdc++-5-dev_5.4.0-6ubuntu1~16.04.9_amd64.deb ...
Unpacking libstdc++-5-dev:amd64 (5.4.0-6ubuntu1~16.04.9) ...
Error: websocket: close 1006 (abnormal closure): unexpected EOF
Error: Get http://unix.socket/1.0: dial unix /var/snap/lxd/common/lxd/unix.socket: connect: no such file or directory
Sorry, Snapcraft ran into an error when trying to running through its
lifecycle that generated the following traceback:
Traceback (most recent call last):
File "/snap/snapcraft/1513/lib/python3.5/site-packages/snapcraft/internal/lxd/_containerbuild.py", line 228, in _container_run
**kwargs)
File "/snap/snapcraft/1513/usr/lib/python3.5/subprocess.py", line 581, in check_call raise CalledProcessError(retcode, cmd)
There are of course workaround for this like “build remotely” or “don’t use the lxd snap”, but I’d like to build on my 64GB RAM multi-core SSD-equipped laptop, and not sit in a queue for a launchpad build bot, and use our tools.
Is there something we can add to snapcraft to allow it to suppress updates while I’m building? It’s really inconvenient.
So, there has seem to be some fixes in the snap part to somehow make use of the older revision directory: I could see that the new revision was created but stuff kept being updated in the old one. Still, for some reason I continued to have issues regarding losing state in Chromium.
For now I gave up and rolled back to Ubuntu’s chromium package and will be using firejail with it.
I never liked the fact that the chromium snap could access my home directory and read/write stuff there (heck, there’s a $HOME/snap to isolate it already), so running it under firejail allows me for more control over that. And yeah, I used to disconnect the chromium:home plug, but snapd would enable it all over again (I reported this sometime back). Plus the snap had links to stuff under $HOME which kind of messed up some stuff when the plug was disabled. So at least for my usage and expectations the way that the chromium snap works is broken.
