Bug#776101: aptitude: hangs forever on 'setting up console-setup (1.116)'
On Sat, 24 Jan 2015 00:38:29 +0100, Axel Beckert <abe@debian.org> wrote:
> Control: reassign -1 console-setup 0.116
>
> Hi,
>
> Gordon Morehouse wrote:
> > running 'aptitude upgrade' followed by 'aptitude update'
>
> You mean "running 'aptitude update' followed by 'aptitude upgrade'",
> don't you?
Ah, yes, indeed. :)
> > on a Debian testing system hangs
>
> How long did you approximately wait?
I was doing other things, so more than 20 minutes.
> > 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.
Okay. Posted to wrong package due to lack of knowledge :)
> > '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?
I didn't look into the process tree, but the system appeared completely idle (or as idle as it can get), with 'top' and 'aptitude' the top users of CPU time.
> > 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.
If it takes 20+ minutes on an Athlon64, there should probably be a status report...?
> 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.
I managed to reboot and then re-run aptitude and it completed without complaint.
Thanks,
-Gordon M.
Reply to: