Ubuntu
nfs-utils package

  1. Bug #1476010
  2. Comment #3

Comment 3 for bug 1476010

Revision history for this message
Martin Pitt (pitti) wrote :

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.