Flatpak updates with systemd

Automatic Update

© Photo by ThisisEngineering RAEng on Unsplash

© Photo by ThisisEngineering RAEng on Unsplash

Article from Issue 270/2023

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).

Figure 1: Systemd distinguishes between system-wide services and those controlled by users. The same principle applies to Flatpak.

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.

Figure 2: The flatpak list command shows you (on the far right) the context in which an application was installed as a Flatpak.

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/
Description=Update user Flatpaks
ExecStart=/usr/bin/flatpak --user update -y

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/
Description=Update system Flatpaks
ExecStart=/usr/bin/flatpak --system update -y

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/
Description=Update user Flatpaks daily

Listing 5

System-Wide Timer

# update-system-flatpaks.timer
# in /etc/systemd/system/
Description=Update system Flatpaks daily

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.

Figure 3: After completing the setup, /etc/systemd/user/ contains a service file and a timer. You should also find the counterparts to these two files in /etc/system/system/.

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.

Figure 4: Want to know when the next update will take place? This command will tell you.

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).

Figure 5: Check the log with journalctl -b | grep flatpak to discover exactly what happened in terms of updates since the last time the computer rebooted.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Flatpak and Snap

    The new container-inspired package formats Flatpak and Snap have landed in the territory occupied by conventional Linux package systems such as RPM and Dpkg.

  • unsnap

    If you want to move away from Ubuntu's Snap package format, the unsnap script removes snaps from your computer and replaces them with Flatpaks where possible.

  • Systemd Timers

    Systemd can start timers that automatically perform tasks at specified times. The configuration files are known as timer units.

  • Universal Package Systems

    Billed as the future of package management, universal package systems like Snappy and Flatpak have failed to live up to their promise.

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

comments powered by Disqus
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.