On Sat, 24 Jan 2015 00:38:29 +0100, Axel Beckert <a...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yffcb-0001rr...@rmm6prod02.runbox.com
