Tips and tricks

Running services after the network is up

To delay a service after the network is up, include the following dependencies in the .service file:

/etc/systemd/system/foo.service

[Unit]    
...
Wants=network-online.target
After=network-online.target    
...

The network wait service of the particular application that manages the network, must also be enabled so that network-online.target properly reflects the network status.

• For the ones using NetworkManager, enable NetworkManager-wait-online.service.
• If using systemd-networkd, systemd-networkd-wait-online.service is by default enabled automatically whenever systemd-networkd.service has been enabled; check this is the case with systemctl is-enabled systemd-networkd-wait-online.service, there is no other action needed.
  For more detailed explanations see Running services after the network is up in the systemd wiki.

Enable installed units by default

This article or section needs expansion.

Reason: How does it work with instantiated units? (Discuss in Talk:Systemd (简体中文)#))

Arch Linux ships with /usr/lib/systemd/system-preset/99-default.preset containing disable *. This causes systemctl preset to disable all units by default, such that when a new package is installed, the user must manually enable the unit.

If this behavior is not desired, simply create a symlink from /etc/systemd/system-preset/99-default.preset to /dev/null in order to override the configuration file. This will cause systemctl preset to enable all units that get installed—regardless of unit type—unless specified in another file in one _systemctl preset'_s configuration directories. User units are not affected. See the manpage for systemd.preset for more information.

Note: Enabling all units by default may cause problems with packages that contain two or more mutually exclusive units. systemctl preset is designed to be used by distributions and spins or system administrators. In the case where two conflicting units would be enabled, you should explicitly specify which one is to be disabled in a preset configuration file as specified in the manpage for systemd.preset.

Sandboxing application environments

A unit file can be created as a sandbox to isolate applications and their processes within a hardened virtual environment. systemd leverages namespaces, white-/blacklisting of Capabilities, and control groups to container processes through an extensive execution environment configuration.

The enhancement of an existing systemd unit file with application sandboxing typically requires trial-and-error tests accompanied by the generous use of strace, stderr and journalctl error logging and output facilities. You may want to first search upstream documentation for already done tests to base trials on.

Some examples on how sandboxing with systemd can be deployed:

• CapabilityBoundingSet defines a whitelisted set of allowed capabilities, but may also be used to blacklist a specific capability for a unit.
  • The CAP_SYS_ADM capability, for example, which should be one of the goals of a secure sandbox: CapabilityBoundingSet=~ CAP_SYS_ADM