Laurent Martelli wrote: > I saw something about this in debian-devel, and I think there's a bug > report now.
Yes, I've been in contact with the package maintainer and here was his response to me. Since I had the problem last night, it has not happened again, which I don't really understand, but here's his info about what he's looking for to find it and fix it if someone else runs into the problem. Note: he's not subscribed to Debian-User, so if anyone else runs into this, be sure to try some of the things he's mentioned below... -- Message from Joopje about Update-menus problem below -- (copying to Bug 42051, as it's the same) >From [EMAIL PROTECTED] Wed Jul 28 11:10:34 1999 Subject: Update-menus hanging during dselect / apt-get > I'm copying the package maintainer on this since I didn't see anything > in the bugs database... perhaps I've stumbled on one? Yes, a bug has already been filed. But I'm very glad you didn't notice it (it's not yet on't www.master.org, while it is on master.debian.org), as your bugreport is a *lot* more informative than the one in the BTS! Just one nit: both you and the other bug mailer think about mention what version of menu you are using, or any other packages menu depends on. Could you send me a list of that? (installed versions of menu, libc6, libstdc++2.9-glibc2.1). Thanks. > After a fairly painless upgrade to potato on one system here, I've been > doing the occasional update/upgrade cycle with either dselect or apt-get > and things usually go well. (After I got all the Perl stuff > straightened out... but that's why it's called unstable!) > > Tonight, I seem to be having a recurring problem with Update-menus > hanging and stopping everything right after packages are unpacked by > dselect/apt. Last weekend I've released a new version of menu, that may well have caused this. (Will be sure once you mention what version you are now using). Anyway, it *is* unstable, isn't it? > The output is... > > Upacking replacement foo ... > Update-menus[PID]: further output (if any) will appear in > /tmp/update-menus.PID > > ... where PID is the PID of a copy of update-menus... of course. > > At this point, the whole process hangs and doesn't continue. Ctrl-C > will interrupt, which will kill both update-menus and the script running > which sends the signal to apt that all did not go well with the package. > > Sometimes, running a new dselect/apt session it will get farther along, > but then it hangs again later on another package it seems. OK, thanks. So it isn't reproducable. But the fact that it then hangs later on is actually strange. That shouldn't happen. Could you, in the /etc/menu-methods/menu.config file, change the `verbosity=quiet' line to `verbosity=verbose', and then try to get again that situation where update-menus goes through the first time, but not the second (third, whatever)? I'd be interested to see the output of update-menus in that case (both the first one that does fall through, and the one that `hangs') > Some other output from a `ps aux | grep update` shows that there are two > update-menus running, and I don't know if this is possibly the issue, or > if it's normal for update-menus to have children. One is the PID listed > in the output of apt, the other is one PID LOWER. What happens if you do # kill -SIGUSR1 `expr PID - 1` in a seperate window, while update-menus is `hanging'? Actually that test is rather irrelevant, cause it will almost certainly cause the process to go on smoothly. But anyway, it is a way to `fix' the problem temporarily. Also, I'd like to see what a second update-menus call does the above case. So, please install two packages with update-menus calls in their postinst, wait for update-menus to hang, type "kill -SIGUSR1 `expr PID - 1`", and see what the second postinsts with update-menus in it does. It *should* report nothing at all. Oh, and one more thing: I use apt/dselect, I only use dpkg directly (well during the latst year). Could you check if just typing somthing like # dpkg -i ncftp2_2.4.3-2.deb xwhois_0.3.5-1.deb (or whatever packages you are installing) also has the problem? > I've attempted to exit out of the package selection tools and run > update-menus by hand as root, and that seems to work fine. No errors > output to STDERR or STDOUT, anyway. If you want some more output, you could try update-menus -v and you should see something of a confirmation that everything went OK. > And yes, I did the change suggested > by Joop in moving his config file for the older afterstep stuff from the > example he gives to the live copy... but I'm using WindowMaker anyway, > and Afterstep is rarely used, if at all on this machine. Everything you said suggests that update-menus hasn't started looking at even the menu-entry-files, never mind the menu-methods. So, although any type of experimenting cannot be harmful, I think this is not the most likly place to find clues to the bug. > Anyone have any other ideas on how to catch what's happening to it, or > is this a known issue being discussed elsewhere, and I don't see it > because I only am subscribed to Debian-User? I'm not even subscribed to debian-user:(. Your bugreport was most helpful. Many small things you mention (like update-menus is running under PID and PID-1, etc) really `nearly' pinpoint the location. But not quite. I really would like to reproduce the bug here on my box, but whatever I do it doesn't occur. That's why I ask you for the installed versions of libc and libstdc++2* on your system. Other things I cannot think of right now. Thanks very much for reporting the bug so clearly, -- joostje
