Score:2

Flatpak does not update its apps when run via cron

us flag

This simple script runs correctly when launched manually:

#!/bin/sh

flatpak -y update 2>&1 >> ~/cron/cron-flatpak.log

When run with 00 07 * * * sh ~/cron/cron-flatpak.sh (same regular user, not root crontab), it produces the following:

Looking for updates…


 1.     org.chromium.Chromium.Codecs    stable  u   flathub < 1.1 MB
 2.     org.chromium.Chromium.Locale    stable  u   flathub < 112.8 kB (partial)
 3.     org.qbittorrent.qBittorrent stable  u   flathub < 8.3 MB



Updating 1/3…                                                                 
Warning: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user

Updating 1/3… ██▌                   13%  41.1 kB/s
Updating 1/3… ████████████████████ 100%  674.8 kB/s
Updating 1/3… ████████████████████ 100%  674.8 kB/s
Updating 2/3…                                                                 
Warning: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user

Updating 2/3… ████████████████████ 100%  592 bytes/s
Updating 3/3…                                                                 
Warning: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user

Updating 3/3… ████████████████████ 100%  0 bytes/s
Updates complete.

Afterwards, the versions seem to match what's listed on flathub.io, but the script tries to update everything over and over again on each run. Any suggestions?

ETA: Okay people, I'll be testing the approaches you suggested and I will accept one answer or the other after I manage to make the thing work. Going to take a while since every single iteration requires a new app version rolled out on flathub.

wizardpurple avatar
cn flag
You can install specific versions of flatpaks, such as older versions, using ```flatpak remote-info --log flathub PACKAGE_NAME``` to list the commit history, and then 'update' the flatpak to that specific version: ```flatpak update --commit=COMMIT_STRING PACKAGE_NAME```. Use the ```--user``` flag for user packages. For system packages, sudo is required install a specific commit.
us flag
@wizardpurple Rolling my test app back to an older commit saved me a lot of time. Thanks.
Score:4
cn flag

It's not so much a solution as a workaround, or possible clue, but installing Chromium with the --user flag (flatpak uses --system by default) and updating works fine in cron.

flatpak install flathub org.chromium.Chromium # default, has cron issues
flatpak install --user flathub org.chromium.Chromium # no cron issues

Unfortunately, I'm unsure why the ability to update system flatpaks is dropped in cron—at least for the Chromium flatpak since it looks like the third flatpak was able to update just. Maybe the issue is with that particular flatpak.

Edit: I missed the third error in the output, it was not unique to Chromium.

Edit 2: Just some further clarification/steps for using flatpak's --user flag. Since system and user packages are managed separately, this means adding/removing remotes, installing, and updating must also be done separately. A user package cannot pull from a system remote and vice versa.

# add a user remote
flatpak remote-add --if-not-exists --user REMOTE_NAME REMOTE_ADDRESS

# updates just user packages
flatpak update --user
us flag
Since cron runs its jobs as the same interactive user who executed `crontab -e`, the only difference between installing flatpak apps for system and for user must be in directories, right?
wizardpurple avatar
cn flag
Yes, ```--user``` packages will be installed to ```$HOME/.local/share/flatpak/app/``` and ```--system``` (the default method) are in ```/var/lib/flatpak/app/```
us flag
Accepting this one because it's cleaner ideologically, especially when user sets up flatpak from scratch.
Score:1
it flag

Jobs run through cron, or at, or batch, aren't run in the same runtime environment that you have on your desktop. None of your PATH changes, or other environment variable settings are automatically propagated to your cron job. For example, there's no $DISPLAY, so GUI programs need special treatment (read man xhost).

One can set environment variables for all one's cron jobs in the crontab file Read man 5 crontab.

Look at the results of echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias in each of your environments.

Since the command part of the crontab line is, by default, interpreted by /bin/sh, which has a simpler syntax than /bin/bash, I recommend having command be a call to a bash script (executable, mounted, starts with #!/bin/bash) which sets up the environment, then calls the desired program.

us flag
The output of `set` for my user account is 72 KB and for cron is 406 bytes. Even after excluding the obviously irrelevant differences, testing it line-by-line would take years. Is there a way to just load my whole user environment into cron? I'm reading up on sourcing the environment variables now; pretty sure it's a dead end because it sounds too obvious. Would have been mentioned somewhere if it worked.
Score:0
us flag

Found a cheap and dirty solution: run flatpak via cron with sudo. There are at least 3 ways to do it; I went with adding flatpak to sudoers like this:

Cmnd_Alias FLATPAK = /usr/bin/flatpak
myusername ALL=(ALL) NOPASSWD: FLATPAK

The script changes accordingly:

#!/bin/sh

sudo /usr/bin/flatpak -y update 2>&1 >> ~/cron/cron-flatpak.log

With these modifications, everything updates without a hitch. The real reason is most likely not the privileges per se but some other change in the environment, but at least it does not make me reinstall everything.

If anyone thinks it's a bad idea, please explain why.

wizardpurple avatar
cn flag
What about running it from root's crontab? No need to add flatpak to sudoers that way.
us flag
This would be the fourth way. I'm still curious why it works, but we'll probably never know.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.