[systemd-devel] [Install] section of symlinked unit file ignored if drop-in file is used
John Gallagher
john.gallagher at delphix.com
Thu May 24 00:06:34 UTC 2018
If I have a unit file for a service that lives off the unit file
search path, I can link it, and then enable it using the service name
instead of the full path of the unit file:
$ cat foo.service
[Service]
Type=simple
ExecStart=/bin/sleep 100000000
[Install]
WantedBy=multi-user.target
$ sudo systemctl link ~/foo.service
Created symlink /etc/systemd/system/foo.service →
/export/home/delphix/foo.service.
$ sudo systemctl enable foo
Created symlink
/etc/systemd/system/multi-user.target.wants/foo.service →
/export/home/delphix/foo.service.
If I add a drop-in file for the service though, enabling the service
using the service name does not behave the same way:
$ cat /etc/systemd/system/foo.service.d/env.conf
[Service]
Environment=FOO=bar
$ sudo systemctl enable foo
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means 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, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.
I get the warning above, and the expected link in
/etc/systemd/system/multi-user.target.wants/ is not created. I can
work around this behavior by doing the enable using the path of the
unit file:
$ sudo systemctl enable ~/foo.service
Created symlink
/etc/systemd/system/multi-user.target.wants/foo.service →
/export/home/delphix/foo.service.
The [Install] section of the unit file being ignored or respected
based on the presence or absence of a drop-in file seems inconsistent
to me, but I am fairly new to systemd, so I may be missing something.
Is this behavior expected?
Thanks,
John
More information about the systemd-devel
mailing list