Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

[Michael Biebl]

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 at pluto:~# systemctl status test.service
> ● test.service - Test
>      Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor preset: enabled)
>      Active: inactive (dead)
> root at pluto:~# service test status
> ● test.service - Test
>      Loaded: loaded (/usr/lib/systemd/system/test.service; static; vendor preset: enabled)
>      Active: inactive (dead)
> root at pluto:~# systemctl start test
> root at 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 at 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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200619/6952cbc2/attachment.sig>