[systemd-devel] Why is the [Install] section in a drop-in not respected?

[林自均]

Hi folks,

I learned that [Install] section in a drop-in is not respected. This
behavior is documented, but I failed to see *why*.

I found this related GitHub issue:
https://github.com/systemd/systemd/issues/1774, and here is the quote from
"poettering commented on 5 Nov 2015":

> Well, this has been requested before, but generally, install info is
something that is provided by the unit file vendor in the unit files.
drop-ins and symlinks in /etc are user extensions however. "systemctl
enable" is for applying that install info to /etc. It would be
contradictory to use user configuration to create user configuration
though. Hence we do not respect install info in drop-ins.

However, I don't think it's contradictory since drop-ins are not always
user configuration. For "s.service", the drop-ins in
/usr/lib/systemd/system/s.service.d/
and /var/run/systemd/generator/s.service.d/ are respected, but they are not
user configurations.

For example, one can create a package that includes 2 things:

1. a target unit called "remote-access.target"
2. a systemd generator that generates the following drop-ins for
"sshd.service", "telnetd.service" and "vnc.service":

[Unit]
PartOf=remote-access.target

[Install]
WantedBy=remote-access.target

That way, after a user typed "systemctl enable sshd telnetd vnc", he/she
can:

- systemctl start remote-access.target
- systemctl stop remote-access.target

to conveniently start/stop all remote access services.

In conclusion, I consider drop-ins as a way to enhance the original unit
files. Just like [Unit], [Service] or any other sections, [Install] should
be enhance-able too.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171017/461fe819/attachment.html>