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
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
