Hi Michael, First, thanks for your help and heads up with this issue.
On Tue, Aug 06, 2019 at 09:15:04AM +0200, Michael Biebl wrote: > I don't think this is a proper fix. After all, you typically want a > daemon to be restarted after upgrades so (security) fixes are applied. I agree with you, actually I'm not very happy with the solution either. From my perspective (by now) I'd rather to keep the service running and then the user could restart it under supervision after the upgrade is done than let it keeping failing under the upgrade where maybe the final user would not notice it after something is on fire. I'm looking forward to find a better solution for this. > I also notice, that the above commit contains other (unrelated) changes > which are not mentioned in the changelog. It's not a good idea try several fixes and (ab)use `git commit --amend` I lost control of some changes (related with the fix). Totally my bad, Sorry about this! I'll fix it in the next revision. > For the time being, I would suggest a different workaround, ie. > restarting rpcbind.service and rpcbind.socket sequentially (or only > rpcbind.service, I think that should be sufficient) > So somehting like this: > override_dh_installsystemd: >  dh_installsystemd rpcbind.socket > dh_installsystemd rpcbind.service I have tried this however rpcbind keeps failing at upgrade after the workaround > I'm not yet sure if this is a bug in systemd itself, in rpcbind or > debhelper for generating such a code sequence, so CCing all affected > parties. Similar bug was filed two years ago upgrading to stretch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865617 -- Josue
signature.asc
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
