Am 19.06.20 um 07:19 schrieb Thijs Kinkhorst: > Hi Michael, > > On Wed, June 17, 2020 22:48, Michael Biebl wrote: >> Systemd itself does indeed search /usr/lib/systemd/system . Our >> internal/Debian tooling though >> (dh_installsystemd/invoke-rc.d/service/...) currently only handles files >> from /lib/systemd (mostly for historical reasons where a /usr on a >> separate partition mounted during late boot was still supported). >> >> So, theoretically, you can install unit files in /usr/lib/systemd/system >> and systemd will process them. What you don't get is full Debian >> integration. > > Well, I'm quite sure in the sense that I had a unit file in > /usr/lib/systemd/system but indeed commands like "service" did not work. I > find it unexpected behaviour that systemd reports that it searches the > directory but at the same time something like "service x start" does not > work. > > Also I found > https://lintian.debian.org/tags/systemd-service-file-outside-lib.html > which explicitly says: "Systemd in Debian searches for unit files in > /lib/systemd/system/ and /etc/systemd/system. Notably, it does not look in > /usr/lib/systemd/system/ for service files." > > So I think the most clear way forward is either that it does not report > this directory as being searched, or all the tools do in fact work with > this directory. A mid way where some things work and others do not, is > confusing to me at least.
Well, if systemd would be reporting that it does not search this path, then this would be wrong information, as indeed systemd does look there. So I do not plan to patch systemd(-analyze) to do that. It's just that our Debian policy so far has been, that files need to be installed in /lib only (mostly for historical sake). I just checked again and afaics service, invoke-rc.d and deb-systemd-invoke should handle unit files in /usr/lib/ just fine, as they don't use any hardcoded paths, but call systemctl internally: > root@pluto:~# systemctl status test.service > ● test.service - Test > Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor > preset: enabled) > Active: inactive (dead) > root@pluto:~# service test status > ● test.service - Test > Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor > preset: enabled) > Active: inactive (dead) > root@pluto:~# systemctl start test > root@pluto:~# service test status > ● test.service - Test > Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor > preset: enabled) > Active: active (exited) since Fri 2020-06-19 10:13:02 CEST; 13s ago > Process: 27396 ExecStart=/bin/true (code=exited, status=0/SUCCESS) > Main PID: 27396 (code=exited, status=0/SUCCESS) > CPU: 3ms > > Jun 19 10:13:02 pluto systemd[1]: Started Test. > root@pluto:~# invoke-rc.d test status > ● test.service - Test > Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor > preset: enabled) > Active: active (exited) since Fri 2020-06-19 10:13:02 CEST; 2min 44s ago > Process: 27396 ExecStart=/bin/true (code=exited, status=0/SUCCESS) > Main PID: 27396 (code=exited, status=0/SUCCESS) > CPU: 3ms > > Jun 19 10:13:02 pluto systemd[1]: Started Test. update-rc.d does have /lib/systemd hard-coded in make_systemd_links() (although that is only a fall back if the real systemctl is not available), deb-systemd-helper might need some updates as well and then there is obviously debhelper, i.e. dh_installsystemd. Personally, I think we should just move all files to /usr/lib. We might be able to do that semi-automatically by letting dh_installsystemd move them. So far we preferred that all unit files are at a single location, which is why lintian warns if files are installed to /usr/lib.
signature.asc
Description: OpenPGP digital signature
