package nfs-common 1:1.2.8-9ubuntu8.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100

Martin, could you have a look at this bug when you have a chance, please? The cause is quite simple, the systemd unit and the upstart job have differing names. I'm not sure about the correct fix - not least of all because of the interactions between invoke-rc.d and deb-systemd-invoke (which I still consider a bad case of NIH that we should correct at some point) and the differences in the top-level invocations for systemd vs. not ('nfs-utils.service' vs. individual units).

The semantics of the deb-systemd-invoke aren't even right for the postinst currently anyway, because we're calling 'deb-systemd-invoke try-restart' for nfs-utils.service, which is a one-shot service and therefore 'try-restart' has no effect. This looks like a serious bug in the semantics of dh_systemd, as 'try-restart' is a deviation from the established policy that services should be started on upgrade *even if they were not running before*, *unless* the admin has done something to specifically declare the service should not be started. (update-rc.d disable, etc).

Relevant log excerpt:

Unpacking nfs-common (1:1.2.8-9ubuntu8.1) over (1:1.2.8-9ubuntu8) ...
Setting up nfs-common (1:1.2.8-9ubuntu8.1) ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/gssd not found.
dpkg: error processing package nfs-common (--configure):
 subprocess installed post-installation script returned error exit status 100

So this wasn't actually a vivid → wily dist-upgrade, but just upgrading vivid to vivid-updates. Not that it matters much in this case as wily's package is by and large the same.

I tried to reproduce this on vivid, bot with the default (no gssd) and with enabling gssd; but the upgrade, while noisy, works:

Setting up nfs-common (1:1.2.8-9ubuntu8.1) ...
invoke-rc.d: gssd.service doesn't exist but the upstart job does. Nothing to start or stop until a systemd or init job is present.
invoke-rc.d: idmapd.service doesn't exist but the upstart job does. Nothing to start or stop until a systemd or init job is present.

https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-53.2ubuntu4 was supposed to fix this. But the original reporter has 2.88dsf-53.2ubuntu12 installed already, so that's not it.

So I can't yet write a working test case for an SRU. Timothy, can you still reproduce this (try "sudo apt-get install --reinstall nfs-common")? If so, can you run these commands to create the naming compatibility symlinks:

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s nfs-idmapd.service /lib/systemd/system/idmapd.service

and verify that this works now? After that, if you can still reproduce the install error without the symlinks I'd like to ask you some further questions.

> try-restart' is a deviation from the established policy that services should be started on upgrade *even if they were not running before*

try-restart is only done for dh_systemd_start, which handles all units which are not "the main .service" (which is usually accompanied by an init.d script). I. e. timers, .paths, auxiliary services which might be disabled on purpose, etc. It would be dangerous to just restart them all. In this particular case gssd should be handled by the dh_installinit generated snippet, which is just lacking the naming symlink as you already pointed out.

> can you run these commands to create the naming compatibility symlinks:

Sorry, this was wrong. Please use these:

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s /dev/null /lib/systemd/system/idmapd.service

Background: nfs-idmapd.service cnanot be restarted independently. It is bound to/handled by nfs-server.service already.

This bug was fixed in the package nfs-utils - 1:1.2.8-9ubuntu10

---------------
nfs-utils (1:1.2.8-9ubuntu10) wily; urgency=medium

  * debian/nfs-common.links: Add naming compatibility symlinks for
    gssd.service → rpc-gssd.service and idmapd.service → /dev/null (as this
    is bound to/handled by nfs-server.service) to provide a match for the
    upstart job names. (LP: #1476010).

 -- Martin Pitt <email address hidden> Fri, 28 Aug 2015 09:59:48 +0200

HI Martin,

I believe I have upgraded past the version as well. When I run the reinstall I got a 404. After an apt-get update && apt-get upgrade, the reinstall worked without issue.

Today i tried to upgrade xubuntu from 15.04 and i got the same error

Stragely, I still got the same error today during upgrade 15.04 -> 15.10.

I got the error today on upgrade 15.04 -> 15.10, which was carried out immediately after upgrading from 14.04-14.10-15.04.

I did a fresh install of 15.04 a few months ago. Today I updated to 15.10 and got the error.

I got the error today on upgrade 15.04 -> 15.10.

I got the error today on upgrade 15.04 -> 15.10.

I got the error today on upgrade 15.04 -> 15.10. Has anyone found a workaround for this? The following symlinks did not work for me.

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s /dev/null /lib/systemd/system/idmapd.service

Thank you,
Jon