Bug 54560 - systemd does not follow symlinks that point outside of /etc/systemd/system or /usr/lib/systemd/system
Summary: systemd does not follow symlinks that point outside of /etc/systemd/system or...
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-05 14:14 UTC by Ryne McCall
Modified: 2016-06-07 10:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

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.