On Fri, 9 Dec 2016, André Hartmann wrote:
Hi Michael,
Am 09.12.2016 um 12:43 schrieb Michael Chapman:
On Fri, 9 Dec 2016, Michael Chapman wrote:
[...]
> You will need to use the .service extension on at least the first of
> those links. systemd will only consider links in that directory that
> have valid unit names. (I'm pretty sure the intermediate link's name
> doesn't matter, but I wouldn't want to rely on that -- best just to
> use valid full unit names everywhere.)
Oh, something else I thought of... I'm pretty sure it doesn't make sense
having a symlink to /dev/null inside a .wants directory. Really, only
the name of those links are considered. The links aren't actually
dereferenced.
I have to disagree on this, the name does not matter, the link target does
matter (see log below, the relevant status is marked with <---).
Your log only shows that it's the presence of the link that matters, not
what the link is pointing to.
Here, I'll demonstrate:
# cat >/etc/systemd/system/example.service <<EOF
[Unit]
Description=Example
[Service]
ExecStart=/bin/true
[Install]
WantedBy=multi-user.target
EOF
Enabling this creates the symlink:
# systemctl daemon-reload
# systemctl is-enabled example.service
disabled
# systemctl enable example.service
Created symlink from
/etc/systemd/system/multi-user.target.wants/example.service to
/etc/systemd/system/example.service.
# systemctl is-enabled example.service
enabled
But I can make the symlink's target whatever I want... even a dangling
symlink:
# ln -sf the-target-does-not-matter
/etc/systemd/system/multi-user.target.wants/example.service
# systemctl daemon-reload
# systemctl is-enabled example.service
enabled
/dev/null is just fine, it's still a valid link:
# ln -sf /dev/null /etc/systemd/system/multi-user.target.wants/example.service
# systemctl daemon-reload
# systemctl is-enabled example.service
enabled
Only the name of the link is significant:
# mv
/etc/systemd/system/multi-user.target.wants/{example,somethingelse}.service
# systemctl daemon-reload
# systemctl is-enabled example.service
disabled
Put simply, you can't enable and disable services the way you're trying
to do so.
- Michael
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
