[Install] section of symlinked unit file ignored if drop-in file is used

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux