severity 1035543 normal retitle 1035543 e2fsprogs: on an upgrade from bullseye e2scrub-reap.service may be wanted by default.target instead of multi-user.target thanks
On Thu, Jun 01, 2023 at 07:40:25PM +0100, James Addison wrote: > > So it's not a big deal; is that correct so this patch is not worth > > trying to shoehorn in beform Bookworm ships, and this particular patch > > can be safely downgraded from important, right? > > I think all of that is true, yep. OK, I've reset this to normal. > Also, arguing against my own revert-patch: I think it could be said > that multi-user is the "better" target to use here, because the > default could be "graphical" or some later-reached system state > whereas this is a relatively low-level (if small) system cleanup > service. Right, that's I believe the point of bug #991349; it's possible that the system adminsitrator might manually set default.target to point to graphical.target, per [1]. And since multi-user.target is a subset of graphical.target, it makes sense to make the Wanted-by to be multi-user.target. [1] https://www.baeldung.com/linux/systemd-target-multi-user And so it's fair to keep this bug open, but I think it makes it a normal bug, with the resumption that hopefully it can be fixed via deb-systemd-helper or init-system-helpers. In this particular case, since we *always* want it to be default.target, since the whole *point* is to clean up after a failed e2scrub, it seems really unlikely to me that the system administrator would change this. So this is one where it's probably fair for the postinstall script to just fix the wanted-by link **always** if the the systemd unit file says Wanted-by: default.target, and the symlink is inconsistent with it. Maybe this will mess with some kind of hidden systemd rules of the road, but quite frankly, the fact that this is causing so much pain and confusion, I'm not sure I care. > I'd agree with downgrading the severity to below RC (and it's your > package, so feel free, I think? maybe even close it?). If anyone > arrives here/reports other bugs as a result of experiencing it, I > think we can let them know that it's safe to remove the legacy > 'default.target' symlink (does that sound correct too?). I think so. The symlink should *never* be considered normative, right? The unit file should be considered the single source of truth. If the system administrator wants to do something weird, they are supposed to copy /lib/systemd/system/e2scrub_reap.service to /etc/systemd/system/e2scrub_reap.service, and if the symlink is inconsistent with what's in the unit file (with the one in /etc/systemd/... if it exists taking precedence over the one in /lib/systemd/..., we should just fix the symlink. So this should be fixable in deb-systemd-helper, or I can just implement a Big Fat Hammer in e2fsprogs's postinst script. Does that sound right? - Ted
