debathena-pyhesiodfs: Restarting automounter post-install script froze on dist-upgrade

[s4m]

While upgrading from Karmic to Lucid, the post-install script for debathena-pyhesiodfs seemed to freeze (related to me not having valid kerberos tickets at the time?). After canceling with ctrl-c (after a long wait), the remainder of the dist-upgrade proceed without obvious problem, only to run into the same error when doing the (automatically run after install for an upgrade with errors) "dpkg --configure -a". At least, the post-install script for that package should have a timeout or something so that whatever else it does (if anything) doesn't fail if the automounter cannot be restarted.

[broder]

This is sort of strange sounding, and I can't find anything in our postinst that would cause that.

If it still happens for you when you run dpkg --configure -a, can you edit /var/lib/dpkg/info/debathena-pyhesiodfs.postinst, adding set -x just after the shebang, and try running dpkg --configure -a again. You should get a bunch of debugging spew - post that, and we can figure out why it's hanging.

(After making the change, the start of the postinst should look like this:

#!/bin/sh
# postinst script for debathena-python-pyhesiodfs
#
# see: dh_installdeb(1)

set -e
set -x

# summary of how this script can be called:
#        * <postinst> `configure' <most-recently-configured-version>
#        * <old-postinst> `abort-upgrade' <new version>
#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
#          <new-version>
#        * <postinst> `abort-remove'
#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
#          <failed-install-package> <version> `removing'
#          <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

[s4m]

"dpkg --configure -a" worked without problems after a system restart, which is good for me, but makes it hard to replicate that bug.

[broder]

Since you haven't been able to reproduce this, I haven't been able to reproduce this, I can't explain why this would happen if the system is in a normal state, and I haven't heard any other instances of this failure occurring, I'm closing this ticket.