Bug#776101: aptitude: hangs forever on 'setting up console-setup (1.116)'
On Sat, Jan 24, 2015 at 12:38:29AM +0100, Axel Beckert wrote:
> Gordon Morehouse wrote:
> > on a Debian testing system hangs
>
> How long did you approximately wait?
>
> > after similar output from aptitude:
> >
> > Installing new version of config file /etc/console-setup/compose.ISO-8859-3.inc ...
> > Installing new version of config file /etc/console-setup/compose.ISO-8859-4.inc ...
> > Installing new version of config file /etc/console-setup/compose.ISO-8859-7.inc ...
> > Installing new version of config file /etc/console-setup/compose.ISO-8859-9.inc ...
>
> This output is not from aptitude but either from dpkg or ucf.
>
> > Setting up console-setup (1.116) ...
>
> This is output from dpkg, announcing that it will now run
> console-setup's postinst script.
>
> > 'top' shows aptitude taking about 3-4% CPU but it is stuck.
>
> Because aptitude is probably not the one which is working at that
> time. The one which should do something is either a postinst script
> from some to-be-installed package or some trigger. But dpkg would have
> announce triggers. As well as aptitude is mentioning that it's
> re-reading it's database.
>
> Did top show any other child process of aptitude?
>
> > Ctrl-C is not effective.
>
> Ok.
>
> > Kill with SIGTERM does stop the process while breaking terminal
> > echo.
>
> Sure, because it doesn't leave aptitude a chance to do so. IMHO
> expected behaviour.
>
> > It leaves the aptitude /var lockfile dirty.
>
> Dito.
>
> > Running 'sudo dpkg --configure -a' has a couple errors about
> > /var/cache/debconf/config.dat being locked as well.
>
> This sounds as if the aptitude including its children processes were
> killed while debconf tried to ask you a question or -- more likely --
> generate a config file.
>
> I'm quite sure this is no issue with aptitude at all but likely with
> the postinst script of a to-be-installed package. I currently assume
> it's console-setup, also because it's a heavy debconf user. Hence
> reassigning.
This has happened to me with the upgrade to console-setup (1.121) and
after a bit of head scratching, I've narrowed down the cause to the
fact that scroll lock was active on tty1. This blocked setupcon (which is
invoked by the postinst, which itself was a zombie) when trying to write
to /dev/tty1.
I'm not sure where this could be made more resilient; it was an error
on our part to have scroll lock enabled on the console (assuming it
was an accidental keypress that caused that state and not some other
software bug).
Gordon, does that by any chance explain things for you too?
Cheers,
Dominic.
Reply to: