Hi Ted, * Theodore Ts'o <ty...@mit.edu> [2023-05-27 19:45]:
So sure, /etc/systemd.d/system/multi-user.target.wants/e2scrub_reap.service doesn't exist. *But* it still exists in .../default.target.wants/... which seems to be enough to keep the e2scrub_reap service enabled. Right?
Yes, that's fine.
In any case, I am still unclear (a) what is actually broken in this particular setup, since according to systemctl status the systemd unit is apparently still appropriate enabled, even if it isn't via the expected Wanted-b: multi-user.target.
The point of piuparts is that an upgraded system is different to a newly installed system, i.e. that the e2scrub_reap.service symlink lies in a different directory.
And secondly, (b) what is e2fsprogs's control scripts supposed to have done differently? That is, if this is indeed this is a bug in e2fsprogs --- what did I do wrong, and how do I fix it?
Arguably nothing and init-system-helpers/dh_installsystemd should detect the change and move the symlink.
And if the answer is you should never, ever, try to change a Wanted-by line in a systemd script, because debian's systemd unit file infrastructure is too fragile to handle this correctly, given that bookworm is about to ship with "Wanted-by: multi-user.target", what's the best path forward at this point?
For now the best way is to do nothing and wait for the bookworm release.In general there are two things. One is to fix the immediate problem this issue is about and we can still do that in a point release. The other one is to have general support for changing Wanted-by: (or state that it is not supported). I would propose to ask the init-system-helpers/dh_installsystemd maintainers for a general solution and then apply that for a bookworm point release.
Cheers Jochen
signature.asc
Description: PGP signature
