** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. + + [Test Plan] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. + + * if other testing is appropriate to perform before landing this update, + this should also be described here. + + [Where problems could occur] + + * Think about what the upload changes in the software. Imagine the change is + wrong or breaks something else: how would this show up? + + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. + + * This must '''never''' be "None" or "Low", or entirely an argument as to why + your upload is low risk. + + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + + [Original Description] + Upgrading the nfs-common debian package will not restart its services. Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled: $ sudo systemctl enable nfs-utils.service The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's - .wants/ or .requires/ directory. + .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has - a requirement dependency on it. + a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, - D-Bus, udev, scripted systemctl call, ...). + D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some - instance name specified + instance name specified Granted, d/rules of the nfs-utils package doesn't even try: - dh_systemd_enable -p nfs-common nfs-client.target - dh_systemd_enable -p nfs-kernel-server nfs-server.service - dh_installinit -pnfs-common -R - dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service - dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service + dh_systemd_enable -p nfs-common nfs-client.target + dh_systemd_enable -p nfs-kernel-server nfs-server.service + dh_installinit -pnfs-common -R + dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service + dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it: # If the job is disabled and is not currently running, the job is not started or restarted. # However, if the job is disabled but has been forced into the running state, we *do* stop # and restart it since this is expected behaviour for the admin who forced the start. # We don't autostart static units either. The above can be seen while attempting a fresh install (or even upgrade) of nfs-common: (...) Setting up nfs-common (1:1.3.4-2.5ubuntu6) ... Creating config file /etc/idmapd.conf with new version Adding system user `statd' (UID 113) ... Adding new user `statd' (UID 113) with group `nogroup' ... Not creating home directory `/var/lib/nfs'. Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target. Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target. nfs-utils.service is a disabled or a static unit, not starting it. ^^^^^^^^^^^^^^^^^ $ systemctl status nfs-utils.service ● nfs-utils.service - NFS server and client services - Loaded: loaded (/lib/systemd/system/nfs-utils.service; static) - Active: inactive (dead) + Loaded: loaded (/lib/systemd/system/nfs-utils.service; static) + Active: inactive (dead) - - This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started". + This was found while testing the fix for bug #1927745. In that bug, the + affected service is rpc.gssd and it's critical that it be restarted, but + it's not happening. It will only be restarted if nfs-utils.service is + already "started". I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928259 Title: Package upgrade won't restart services To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
