Poor feedback, and no ability to escape, when an installation hangs

[Matthew Paul Thomas]

There are many bug reports about situations where an installation goes part-way through, and then gets stuck. For example, bug 815102, bug 796672, bug 795931, bug 795000, bug 779343, bug 775687, bug 753530, bug 730397, bug 725185, bug 723617, and bug 722814.

When an installation gets stuck like this, Ubuntu Software Center gives no sign that it is stuck, it just says "Applying changes" forever. And it's not obvious how to unstick it, short of restarting the computer.

As long as Ubuntu allows maintainer scripts, and as long as maintainer scripts can do anything they like, it will be possible for an installation to get wedged. And as long as we allow installation of third-party packages, some of those problems will not be fixable by Ubuntu developers.

Therefore, we can't rely just on fixing bugs in individual installation/removal scripts. We should also have a failsafe that stops the operation -- or at least gives you the choice to stop the operation -- once the system can tell that it's not getting anywhere.

Possible definitions of "it's not getting anywhere":
(a) the overall installation, after the download finished, has taken more than 30 minutes
(b) the installation hasn't written to any files in the past 5 minutes
(c) an strace of the installation script shows that it's in a loop
(d) something else
(e) some combination of these.

If you do choose to stop an installation, apt should then do its level best to undo whatever the installation had done so far.

[Sebastian Heinlein (glatzor)]

We could add a terminal widget :) Just kidding.

[Sebastian Heinlein (glatzor)]

In the future apt-brtfs could be the way to go - taking snaphsots of the system and reverting the state on broken operations. But also a problem for systems with /home and /root on the same parition.

We cannot safely kill the maintainer script. We can only try to recover as goog as possible. Running FixIncompleteInstall and FixBrokenDepends (dpkg --configure -a and apt-get install -f)

On older systems a large installation can take longer than 30 minutes. E.g. think of people running on USB drives.

[Sebastian Heinlein (glatzor)]

We could also check the terminal output and changes to the status fd and adding a timeout. Would be the easiest option.

[Launchpad Janitor (janitor)]

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

[David Girault (dfgweb)]

Ahah, this bug from 2011 is still valid in 2017 with Zesty!

Extract from `ps axf` today:

27019 ? Sl 0:00 \_ gdm-session-worker [pam/gdm-password]
27029 tty2 Ssl+ 0:00 \_ /usr/lib/gdm3/gdm-x-session --run-script gnome-session --session=gnome
27031 tty2 Sl+ 1:05 \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keep
27035 tty2 S+ 0:00 | \_ /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-helper intel_backlight
27045 tty2 Sl+ 0:00 \_ /usr/lib/gnome-session/gnome-session-binary --session=gnome
27159 tty2 Sl+ 1:12 \_ /usr/bin/gnome-shell
...
27337 tty2 SLl+ 0:10 \_ /usr/bin/gnome-software --gapplication-service
27973 tty2 Sl+ 0:00 \_ update-notifier
...
28014 ? SNl 0:03 /usr/bin/python3 /usr/sbin/aptd
29484 pts/0 SNs+ 0:00 \_ /usr/bin/python3 /usr/sbin/aptd
29502 pts/0 SN+ 0:00 \_ /bin/sh -c /usr/sbin/dpkg-preconfigure --apt || true
29503 pts/0 SN+ 0:00 \_ /usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt
29505 pts/0 ZN+ 0:00 \_ [dpkg-preconfigu] <defunct>
29491 tty2 S+ 0:00 /usr/bin/perl -w /usr/bin/debconf-communicate