Flatpak updates with systemd
Automatic Update
You can automate Flatpak updates without a package manager using systemd's services and timers.
Alternative package systems such as Flatpak, Snap, and AppImage are becoming increasingly popular. They offer a number of advantages, for both developers and users. For example, experimental software versions can be tested without interfering with the distribution's package management system. You can also run several versions of a software tool for comparison purposes without them interfering with each other. Distribution-agnostic Flatpaks can simplify a developer's job because software only needs to be built in a single format.
Flatpaks also present some disadvantages. In view of the low price of storage media, it is up to you whether Flatpak's greatly increased space requirement poses a disadvantage. However, the update behavior of Flatpaks and AppImages does pose a clear disadvantage. Gnome Software, Plasma Discover, and Mint Update will let you automatically update Flatpaks, but this kind of package management is not to everyone's taste. If you rely on the command line to keep your software up to date, Flatpak's update behavior leaves you completely out in the cold. In fact, you will not even be notified of Flatpaks that need to be updated.
Because the Flatpak developers have not planned any further steps for automated updates, the responsibility for updates lies with the desktop environments. For this reason, I put forth a method that lets systemd users automatically update the Flatpaks installed on their systems based on a schedule with the help of the system and session manager. This method not only relieves you of the need to update manually, but it also demonstrates how easy it is to create systemd services and matching timers.
System and User
Flatpaks can be installed in both the user and the system context. Accordingly, you need to create separate services and timers for both contexts. The /etc/systemd/
directory contains two subdirectories (among others) named user/
and system/
, which contain the service files depending on their purposes (Figure 1).
Only the system administrator can manage the system-wide systemd instance. In addition, there is one instance per user. The instance starts and stops on demand when users log in or log out. A maximum of one user instance per user runs, regardless of how often a user logs in. Only the user (or an administrator) is authorized to manage these user-specific services. The Arch Linux Wiki [1] explains this concept in more detail.
The context in which the services for updating the installed Flatpaks are created depends on whether the Flatpaks were installed in the user or system context. You can discover the details using the flatpak list
command (Figure 2), which shows all installed Flatpaks and runtimes. The right-hand Installation column shows the context in which the Flatpaks were installed. If you have both contexts, you need to create services for both the user and the system.
Quickly Installed
Listing 1 shows a systemd service for a user, which you need to store in the systemd user context as update-user-flatpaks.service
. It can be stored in two locations. If several users use the computer and you want all of them to use the service, /etc/systemd/user/
is the right choice. For single-user systems, store the service in ~/.config/system/user/
instead.
Listing 1
User-Specific Service
# update-user-flatpaks.service # in the folder /etc/systemd/user/ [Unit] Description=Update user Flatpaks [Service] Type=oneshot ExecStart=/usr/bin/flatpak --user update -y [Install] WantedBy=default.target
The easiest way to create the service file is to use the command shown in Listing 2. Enter the text from Listing 1 in your choice of editor, and then save. Follow the same steps for the system-wide variant shown in Listing 3. Name this service file update-system-flatpaks.service
and store it in /etc/system/system
.
Listing 2
Editing the File
$ sudo nano /etc/systemd/user/update-user-flatpaks.service
Listing 3
System-Wide Service
# update-systems-flatpaks.service # in the folder /etc/system/system/ [Unit] Description=Update system Flatpaks After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/bin/flatpak --system update -y [Install] WantedBy=multi-user.target
Now you need to create timers to control the services; you will find the timers in Listing 4 (user-specific) and Listing 5 (system-wide). The two timers, named update-user-flatpaks.timer
and update-system-flatpaks.timer
, are stored in /etc/systemd/user/
and /etc/systemd/system/
respectively.
Listing 4
User-Specific Timer
# update-user-flatpaks.timer # in /etc/systemd/user/ [Unit] Description=Update user Flatpaks daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target
Listing 5
System-Wide Timer
# update-system-flatpaks.timer # in /etc/systemd/system/ [Unit] Description=Update system Flatpaks daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target
The OnCalendar
specification in Listings 4 and 5 lets you adjust for desired update times (Figure 3). If the daily
update option you entered for OnCalendar
does not meet your needs, then you could use, for example, OnCalendar=weekly
for a weekly run.
If needed, however, you can do this in a far more targeted way. To start the update at 6:00pm on the first Saturday of each month, you would use the following entry:
OnCalendar=Sat *-*-1..7:*18:00:00
You can read all about systemd timers in the Arch Linux Wiki [2] if you are interested in a more in-depth approach.
Enabling Timers
Now it's time to enable the timers. To do this for the user, you need the command in line 1 of Listing 6. For the system-wide setup, use the command in line 2 instead. Finally, the call in line 3 tells systemd to reload all configuration files and restart all units. You also run this command after making changes to the files.
Listing 6
Timer and Systemd
01 $ sudo systemctl --user enable --now update-user-flatpaks.timer 02 $ sudo systemctl --system enable --now update-system-flatpaks.timer 03 $ sudo systemctl daemon-reload 04 $ sudo systemd-analyze calendar weekly 05 $ sudo journalctl -b | grep flatpak
The call in line 4 lets you determine when the next update will occur (Figure 4). If you get the correct output, you also know immediately that the service is set up correctly.
If you want to know after the execution date whether the setup was successful, use the command from line 5. You will see the output here, if successful; otherwise you will see flatpak update
(Figure 5).
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.