© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
The partof configuration that upstream has decided to use is certainly a strange way to handle the various services they provide, and I feel like it invites fragility just like this bug, but an upstream discussion certainly is a different matter from fixing this in sru releases now.
The conflict here appears to be that upstream chose to make nfs-utils.service a static unit, while deb-systemd-invoke chose not to (re)start static units. Unfortunately, the reasoning for not (re)starting static units appears to be quite arbitrary:
https:/
My opinion is, if the package maintainer specifically chose to call 'dh_systemd_start' for a service that is static, then the package maintainer clearly knows (or should know) what they are talking about and deb-systemd-invoke should (re)start the service according to the package maintainer's instruction. However changing the script to (re)start static units isn't appropriate for srus (but IMHO should be fixed in Debian).
Of course the "appropriate" way to handle service restarts is for the services to be real, and to use try-restart. That would also handle the many problematic packages that start their services when the package is installed, and frequently those services fail to start due to missing or incorrect 'default' configuration (e.g.: tinyssh, dnsmasq, etc), but that's quite offtopic for this.
This seems fine as a 'least bad' way to handle things for nfs-utils for sru.