Bug 54560

Summary:	systemd does not follow symlinks that point outside of /etc/systemd/system or /usr/lib/systemd/system
Product:	systemd	Reporter:	Ryne McCall <rnmccall>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Ryne McCall 2012-09-05 14:14:40 UTC

I'm running Fedora 17 x86_64.

[root@dvat-dev-rmccall-f17 ~]# rpm -q systemd
systemd-44-8.fc17.x86_64

When I try to `systemctl enable bar.service` (a symlink in /etc/systemd/system pointing to /usr/share/foo/bar.service), I get an error of: "Failed to issue method call: No such file or directory".

I am able to work around this by manually creating the symlink:
[root@dvat-dev-rmccall-f17 multi-user.target.wants]# ls -al bar.service 
lrwxrwxrwx. 1 root root 26 Sep  5 10:13 bar.service -> /usr/share/foo/bar.service

Recreation details:
[root@dvat-dev-rmccall-f17 system]# ls -al /usr/share/foo/bar.service
-rw-r--r--. 1 root root 152 Sep  5 09:22 /usr/share/foo/bar.service

[root@dvat-dev-rmccall-f17 system]# pwd
/etc/systemd/system

[root@dvat-dev-rmccall-f17 system]# ls -al bar.service
lrwxrwxrwx. 1 root root 26 Sep  5 09:19 bar.service -> /usr/share/foo/bar.service
[root@dvat-dev-rmccall-f17 system]# systemctl enable bar.service
Failed to issue method call: No such file or directory

Comment 1 Dimitri 2013-04-07 19:06:50 UTC

Same here with Mageia 3 (Cauldron), systemd 195.

Having an ability to follow symlinks that point outside unit dir may be very helpful sometimes. I'm now packaging Zabbix 2.0 for inclusion into Mageia release. Zabbix's database backend can't be selected in runtime, so you have to compile 3 versions (MySQL, PostgreSQL and SQLite3) and choose between them. I've decided to use alternatives mechanism to switch between server executables and corresponding systemd units (units are different because of dependencies on different database services). In Fedora, all the unit files are put into /usr/lib/systemd/system directory, thus exposing 4 services (main symlink and 3 actual units). I've decided not to pollute the directory and to put unit files, say, in /usr/share/zabbix/systemd. But systemd is not able to load such a unit because it tries to open unit file with O_NOFOLLOW.

Comment 2 Lennart Poettering 2016-06-07 10:34:10 UTC

So, current systemd versions will actually follow symlinks in "systemctl enable", but only if they are located in /usr, but not when located in /etc. This is because "systemctl enable" is about creating and removing symlinks in /etc, and we really won't want bsae our decisions what symlinks to create or remove on the symlinks that were created before. Closing as fixed hence.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.