Automatic Update

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.

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

$ sudo nano /etc/systemd/user/update-user-flatpaks.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.

# update-user-flatpaks.timer
# in /etc/systemd/user/
[Unit]
Description=Update user Flatpaks daily
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target

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

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.

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.