Systemd-Overrides: Customization of system services via drop-in

Without changing the delivered service files

The packages of many programs contain systemd service files so that the installed services run in the background or are executed periodically. However, it sometimes happens that the files are not compatible with your own setup and need to be adapted.

For example, the unit file for the Mattermost server from the Arch repository looks like this in excerpts:

[Unit]
Description=Mattermost Chat Server
After=mysqld.service
After=postgresql.service

[Service]
Type=simple
User=mattermost
[...]
ReadWritePaths=/etc/webapps/mattermost/config.json
[...]
ProtectSystem=strict
[...]

ProtectSystem=strict ensures that the process is only allowed read and write access in the specified ReadWritePaths¹.
In my system, however, I have the memory for attachments sent in the chat on a mounted storage, as this data would go beyond the scope of my system SSD in the long term. As praiseworthy as this secure standard configuration is, it also brings with it the problem that Mattermost is not allowed to use the storage location under /media/store/mattermost.

Now, of course, you can simply adapt the supplied service file and adapt the directive ReadWritePath to your own requirements, but the next update can then lead to one of the following problems: Either the service file is again replaced by the one from the package or necessary changes from the upstream do not reach your own system. Especially with services that are exposed on the web, the latter is also a security risk and therefore not recommended.

Systemd-Overrides

Systemd also provides the solution to this problem: it is possible to create special override files which then simply change individual values from the original file without editing them directly.
The easiest way is to use the command systemctl edit <service>, in this example systemctl edit mattermost.service. An editor is opened, which either creates a new override file or opens one that has already been created. In addition, the entire file is commented out in the editor so that the original file can be easily viewed during editing.

### Editing /etc/systemd/system/mattermost.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
ReadWritePaths=/etc/webapps/mattermost/config.json /var/mattermost /media/store/mattermost

### Edits below this comment will be discarded


### /usr/lib/systemd/system/mattermost.service
# [Unit]
# Description=Mattermost Chat Server
# After=mysqld.service
# After=postgresql.service
[...]

In this file, all values can now be adapted to the needs of your own system, but you must always pay attention to the sections. After saving, systemctl status <service> also shows that the unit configuration has been extended by means of another file:

❯ sudo systemctl status mattermost
● mattermost.service - Mattermost Chat Server
    Loaded: loaded (/usr/lib/systemd/system/mattermost.service; enabled; preset: disabled)
    Drop-in: /etc/systemd/system/mattermost.service.d
             └─override.conf

the file /etc/systemd/system/mattermost.service.d/override.conf was loaded as a drop-in, both files are merged and the result is used as the configuration.
Changes to the unit file can therefore be imported without further ado, as it is never changed and the necessary local adaptations are always loaded at runtime. In the case of extensive changes, a complete copy of the file can also be created using systemctl edit --full <service>, in which case future updates will of course most likely be overwritten again and again and you are again completely responsible for the status of the service configuration.