On Mon, Mar 23, 2009 at 04:32:20PM +0100, Michael Prokop wrote:
> Package: menu
> Version: 2.1.41
> Severity: normal
>
>
> Using automatic installation via FAI I see a hanging "update-menus
> --trigger" call causing the build to fail:
>
> root 22433 0.0 0.2 2696 1312 pts/0 S+ 14:57 0:00 /bin/sh
> /var/lib/dpkg/info/menu.postinst triggered /usr/share/menu
> root 22434 97.6 0.2 3144 1236 pts/0 R+ 14:57 2:24 update-menus
> --trigger
>
> strace-ing the PID outside the chroot gives me tons of EBADF which
> might be the reason for the 100% cpu load and the hanging process:
>
> [...]
> read(4293087900, 0xf7f18000, 8192) = -1 EBADF (Bad file descriptor)
> read(4293087900, 0xf7f18000, 8192) = -1 EBADF (Bad file descriptor)
> read(4293087900, 0xf7f18000, 8192) = -1 EBADF (Bad file descriptor)
> read(4293087900, 0xf7f18000, 8192) = -1 EBADF (Bad file descriptor)
> [...]
>
> Killing the update-menus process and manually invoking update-menus
> inside the chroot displays:
>
> # update-menus -v
> update-menus[12725]: Dpkg is not locking dpkg status area, good.
> update-menus[12725]: Reading installed packages list...
> acpi-support
> acpi-support-base
> acpid
> adduser
> [...]
>
> -> it displays the whole package list and then it just hangs (same
> problem as running via FAI).
This is interesting because 'update-menus -v' should not display the
package list. So there seems to be a problem with the call to dpkg-query:
string inst_states="installed\\|triggers-awaited\\|triggers-pending";
string pkgs = "dpkg-query --show --showformat=\"\\${status} \\${provides}
\\${package}\\n\" | sed -n -e \"/" + inst_states
+ " /{s/^.*\\("+inst_states+"\\) *//; s/[, ][, ]*/\\n/g; p}\"";
pkgs = "exec /bin/bash -o pipefail -c '" + pkgs + "'";
FILE *status = popen(pkgs.c_str(), "r");
> Funnily it works when invoked through strace:
>
> # strace -o /tmp/log -ffff update-menus -v
> update-menus[11649]: Dpkg is not locking dpkg status area, good.
> update-menus[11649]: Reading installed packages list...
> update-menus[11649]: Reading translation rules in
> /etc/menu-methods/translate_menus.
> update-menus[11649]: Reading menu-entry files in /etc/menu/.
> update-menus[11649]: 0 menu entries found (0 total).
> update-menus[11649]: Reading menu-entry files in /usr/lib/menu/.
> update-menus[11649]: 0 menu entries found (0 total).
> update-menus[11649]: Reading menu-entry files in /usr/share/menu/.
> update-menus[11649]: 38 menu entries found (38 total).
> update-menus[11649]: Reading menu-entry files in /usr/share/menu/default/.
> update-menus[11649]: 0 menu entries found (38 total).
> update-menus[11649]: Running menu-methods in /etc/menu-methods/.
> update-menus[11649]: Running method: /etc/menu-methods/fluxbox
> #
>
> Do you have any idea what's going on here?
I wonder if your system somehow set signal handling to non-default
value and that interfer with update-menus.
Maybe this bug is related to bug 511698 (in experimental).
> Please let me know if you need any further information, I've a
> chroot available where I can easily reproduce/work on the problem.
1) does 'update-menus --stdout' work ?
2) does 'update-menus --stdout | install-menu -v /etc/menu-methods/fluxbox'
3) what file do you have in /etc/menu-methods ?
Cheers,
--
Bill. <[email protected]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
