update-manager hangs during pre-config

[Nick Moffitt]

I've noticed this in raring with certain kernel packages (though a re-try usually does fine). Basically it looks like there's some sort of deadlock. I tried attaching apport-bug to the aptd, but it just whined that there was no "program" associated with that pid. Perhaps because it's root?

Here's a snippet of `ps fauxw` to show what's going on:

    nick 13113 0.5 3.3 789380 132876 ? SNl 07:36 0:33 /usr/bin/python3 /usr/bin/update-manager --no-update --no-focus-on-
    nick 13923 0.0 0.8 382532 32932 ? SNl 08:43 0:00 \_ /usr/bin/perl -w /usr/bin/debconf-communicate
    root 13808 0.1 2.0 262304 80948 ? SNl 08:42 0:04 /usr/bin/python3.3 /usr/sbin/aptd
    root 13819 0.0 1.2 262488 49980 pts/16 SNs+ 08:42 0:00 \_ /usr/bin/python3.3 /usr/sbin/aptd
    root 13820 0.0 0.0 0 0 pts/16 ZN+ 08:42 0:00 \_ [dpkg] <defunct>
    root 13918 0.0 0.0 4440 624 pts/16 SN+ 08:43 0:00 \_ /bin/sh -c /usr/sbin/dpkg-preconfigure --apt || true
    root 13919 0.0 0.3 67020 15716 pts/16 SN+ 08:43 0:00 \_ /usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt
    root 13921 0.0 0.0 0 0 pts/16 ZN+ 08:43 0:00 \_ [dpkg-preconfigu] <defunct>

I usually just solve this by killing that dpkg-preconfigure process and letting all the apt machinery clean up after it. I'm not sure how to get good debug info out of a running Perl process, but here's open files and an strace -p:

    /proc/13919/fd/:
    total 0
    lr-x------ 1 root root 64 Apr 3 09:24 0 -> /dev/tty
    lrwx------ 1 root root 64 Apr 3 09:24 1 -> /dev/pts/16
    lrwx------ 1 root root 64 Apr 3 09:24 2 -> /dev/pts/16
    lrwx------ 1 root root 64 Apr 3 09:24 3 -> socket:[756505]
    lrwx------ 1 root root 64 Apr 3 09:24 4 -> /var/cache/debconf/config.dat
    lrwx------ 1 root root 64 Apr 3 09:24 5 -> /var/cache/debconf/passwords.dat
    lrwx------ 1 root root 64 Apr 3 09:24 54 -> /dev/pts/15
    lrwx------ 1 root root 64 Apr 3 09:24 6 -> /var/cache/debconf/templates.dat
    lr-x------ 1 root root 64 Apr 3 09:24 7 -> pipe:[756506]

    # strace -p 13919
    Process 13919 attached - interrupt to quit
    read(3,

I guess it's waiting for input from the program at the other end of that pty. I'm not sure if that's aptd that's meant to do that, or the debconf-communicate or some other piece of update-manager.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: update-manager 1:0.185
ProcVersionSignature: Ubuntu 3.8.0-16.26-generic 3.8.5
Uname: Linux 3.8.0-16-generic x86_64
ApportVersion: 2.9.2-0ubuntu5
Architecture: amd64
Date: Wed Apr 3 09:17:58 2013
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/update-manager
GsettingsChanges:
 b'com.ubuntu.update-manager' b'first-run' b'false'
 b'com.ubuntu.update-manager' b'launch-time' b'1364971684'
 b'com.ubuntu.update-manager' b'show-details' b'true'
 b'com.ubuntu.update-manager' b'window-height' b'610'
 b'com.ubuntu.update-manager' b'window-width' b'968'
InterpreterPath: /usr/bin/python3.3
MarkForUpload: True
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: update-manager
UpgradeStatus: Upgraded to raring on 2013-03-19 (14 days ago)

[Nick Moffitt (nick-moffitt)]

er of course I meant the other end of the socket, not the pty.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Colin Watson (cjwatson)]

This looks like the bug I fixed in aptdaemon 1.0-0ubuntu9. What version of aptdaemon do you have installed?

[Brian Murray (brian-murray)]

The version of aptdaemon can be found in dependencies.txt:

aptdaemon 1.0-0ubuntu8
aptdaemon-data 1.0-0ubuntu8

I'm going to mark this as a duplicate then.