systemd user units and links

2015-12-02 • 2 min read • Tags: Comp Sysadm Linux

I tried recently to launch automatically some user programs with systemd, instead of say .xprofile.

I also happen to share some dotfiles across multiple users/environments. So I went ahead and created a /path/to/dotfiles/.config/systemd/user/afuse.service. But when creating a link in ~/.config/systemd/user to this file and enabling it, I got:

» systemctl --user enable afuse
Failed to execute operation: Too many levels of symbolic links

The reason is a design decision. Namely unit files must not be links, which is enforced with O_NOFOLLOW.

But there’s a hidden workaround: enable the file (full path), without creating the link in ~/.config/systemd/user beforehand.

» systemctl --user enable /path/to/dotfiles/.config/systemd/user/afuse.service
Created symlink from /home/foudil/.config/systemd/user/default.target.wants/afuse.service to /path/to/dotfiles/.config/systemd/user/afuse.service.
Created symlink from /home/foudil/.config/systemd/user/afuse.service to /path/to/dotfiles/.config/systemd/user/afuse.service.
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

We can safely ignore the warnings. The afuse.service. unit is enabled:

» systemctl --user start afuse
» systemctl --user list-units afus\*
UNIT          LOAD   ACTIVE SUB     DESCRIPTION
afuse.service loaded active running afuse sshfs automounter