Prevent auto updates (refresh) of my app when it is running

johannesjo · October 13, 2021, 8:24pm

Hello!

I am the developer of Super Productivity which is an open source app mainly distributed as snap. The app is based on electron and uses IndexedDB as a data-source. Unfortunately there is an issue: Whenever snapd automatically tries update the app the database connection is lost and there is no way to recover from it (apart from restarting the app). Is there anyway to prevent this updates when the app is running (from the app itself, as most of my users probably just run snap as it is configured out of the box)?

ogra · October 13, 2021, 9:12pm

i believe

is soon becoming a default so that apps should not refresh while running but notify the user to close and update it …

until it is fully there you can advise your users to enable the experimental feature via

snap set system experimental.refresh-app-awareness=true

(probably show them a popup on first start of the app to tell them about it)

johannesjo · October 15, 2021, 9:42am

Thank you very much for the reply!

Is there maybe some way to work around this issue by using the pre-refresh hook?

ogra · October 15, 2021, 10:03am

no, the hooks run as root and are usually quietened for anything interactive unless they fail …

while you could add something like logger -t $SNAP_NAME "please enable foo" to the hook, that would only end up in the journal…

you could either add something to electron that gets shown on startup like:

github.com

ogra1/mattermost-client/blob/master/electron/main.js#L160


} else {
  app.on('second-instance', (event, commandLine, workingDirectory) => {
    if (mainWindow) {
      if (mainWindow.isMinimized()) mainWindow.restore()
      if (!mainWindow.isVisible()) mainWindow.show()
      mainWindow.focus()
    }
  })
  app.on('ready',  () => {
    if (!store.get('server')) {
      prompt({
        title: 'Mattermost Server',
        label: 'Enter your mattermost server URL:',
        value: 'https://demo.mattermost.com',
        inputAttrs: {
            type: 'url'
        },
        type: 'input'
      })
      .then((r) => {

or use a command-chain script, ship something like yad in your snap and do it like:

github.com

ogra1/vlc-pi-snap/blob/master/scripts/checks.sh

#! /bin/sh

[ -e "$SNAP_USER_DATA/.check-complete" ] && exec "$@"

if ! id -Gn | grep -q video; then
  yad --text "<b>Error, can not open video playback device \!</b>\n\nThe user $LOGNAME is not in the "video" group.\nPlease execute:\n\n    <b>sudo usermod -a -G video $LOGNAME</b>\n\nIn a Terminal, afterwards log out and back in again." \
    --borders=5 --center --on-top --undecorated \
    --skip-taskbar && exit 0
fi

if ! snapctl is-connected hardware-observe; then
  yad --text "<b>Error, can not get status of video playback device \!</b>\n\nPlease connect the hardware-observe snap interface\nwith the command:\n\n    <b>sudo snap connect vlc-pi:hardware-observe</b>\n\nOr through the Permissions UI in the snap-store application" \
    --borders=5 --center --on-top --undecorated \
    --skip-taskbar && exit 0
fi

if [ ! -d "$SNAP_USER_COMMON/.local/lib/locale/$LANG" ]; then
  yad --text "\nGenerating VLC translations for:\n\n\t$LANG" \
    --borders=10 --no-buttons --center --on-top \
    --undecorated --skip-taskbar --timeout=10 \

This file has been truncated. show original

(also see the snapcraft.yaml, how yad is shipped (in the init-checks part) and how the command wrapper is used )

johannesjo · October 15, 2021, 10:32am

Alright! Thank you very much for the quick and extensive help! Much appreciated (didn’t expect this tbh :))! I’ll stick with informing my users about this then.

johannesjo · October 18, 2021, 6:32pm

I recognized that the auto update is not the only thing causing this error. I haven’t been able to put my finger on it, but this is definitely snap specific and occurs every once in a while, especially if I leave the app running for longer periods of time. snap set system experimental.refresh-app-awareness=true is set, so the auto refresh should not be the (only) problem here.

I suspect that some sort of file access might be responsible for this. Is it theoretically possible for the snap container or snapd to access, copy, move files in the projects config folder (e.g. /home/user/snap/superproductivity/1446/.config) in such a manner even when automated updates are disabled?

ogra · October 18, 2021, 7:47pm

only when updating /home/user/snap/superproductivity/1446 will be touched (content is copied to the dir of the next version) and the current/ symlink gets updated … during normal operation nothing of the snap ecosystem should touch it, only your app would …

if you want to avoid copying the config files/dirs, you should use $SNAP_USER_COMMON, i.e. /home/user/snap/superproductivity/common to store such files. this dir is persistent and gets never touched …

johannesjo · October 22, 2021, 12:36pm

Thank you very much for your answer! Using the common dir seems to work well as far I’ve tested this. Is there any reason, why this might NOT be a good idea (as it is not configured to be like this)?

ogra · October 22, 2021, 12:47pm

snaps use the versioned config dirs by default so that a “snap revert myapp” will get you the matching config file for the matching binary, so API, ABI and configuration options are always the matching version for the running version of the app …

if you use the /common dir you have to take care for this yourself … but if your config options do typically not change their naming in incompatible ways there should be no issues with that

johannesjo · October 22, 2021, 2:34pm

Alright! Thank you very much for the explanation.