Description of problem: I included various packages missing from Live successfully and then notice that there were pk-command-not-found processes hanging around eating cpu cycles which is not nice. (Now after uninstalling PackageKit-command-not-found, "killall pk-command-not-found" and reinstalling it - nothing seems to happen: it just shows "Command not found." and seems to give up: so no gdb backtrace yet.) Version-Release number of selected component (if applicable): PackageKit-command-not-found-0.5.4-0.1.20091029git.fc12 How reproducible: every time? Steps to Reproduce: 1. install packages of missing commands (wget, svn, git, etc) 2. run top later Actual results: 2. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11028 jens 20 0 9676 2116 1740 R 22.2 0.1 86:52.30 pk-command-not- 14844 jens 20 0 9676 2092 1792 R 22.2 0.1 66:55.65 pk-command-not- 17217 jens 20 0 9680 1900 1612 R 21.9 0.1 15:53.92 pk-command-not- 12272 jens 20 0 9676 2120 1740 R 21.6 0.1 81:01.22 pk-command-not- Expected results: no hanging processes Additional info: testing rocks
Is this after installing from the live cd, or while running the live image ? The live image may need special-casing because we pretty much neuter PackageKit when running uninstalled. Richard, does this cause problems for command-not-found ? gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t string /apps/gnome-packagekit/frequency_get_updates never >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t string /apps/gnome-packagekit/frequency_get_upgrades never >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t string /apps/gnome-packagekit/frequency_refresh_cache never >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/notify_available false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/notify_distro_upgrades false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/enable_check_firmware false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/enable_check_hardware false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/enable_codec_helper false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/enable_font_helper false >/dev/null gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-packagekit/enable_mime_type_helper false >/dev/null
(In reply to comment #1) > Is this after installing from the live cd, or while running the live image ? After installing
Here's what gdb is saying #0 0x005a2416 in __kernel_vsyscall () #1 0x008da22b in tcsetattr (fd=0, optional_actions=0, termios_p=0xbffd3ad4) at ../sysdeps/unix/sysv/linux/tcsetattr.c:84 #2 0x0804d353 in pk_console_getchar_unbuffered () at pk-console-shared.c:82 #3 pk_console_get_prompt () at pk-console-shared.c:110 #4 0x0804c524 in main (argc=2, argv=0xbffd3ce4) at pk-command-not-found.c:766 I wonder if this might be related to the extra "Command not found." output that appears after the missing command installation.
The original process seems to fork to a child and then exit normally after the package installation completes. This makes me think it may be related to bug 533663.
Here is how I can reproduce a rogue pk-command-not-found process that eats 100% cpu: 1. don't have powertop installed 2. run powertop 3. say y when pk-command-not-found asks 4. after the installation succeeds, pk-command-not-found asks again 5. hit enter 6. you are back at the prompt, with pk-command-not-found eating 100% cpu
Right, thanks for the backtrace. I've found the bug, in that cnf tries to re-exec _itself_ after successful installation, when it should be trying to re-exec the program that it just installed. This worked for so long as the second cnf process was checking if the program was already installed as a sanity check, but the unbuffered input somehow went crazy. Anyway, fixing the original bug makes things work swimmingly for me. commit 7005e0af84874207ab6863f18ac48508237ced5c Author: Richard Hughes <richard> Date: Mon Nov 9 09:42:23 2009 +0000 cnf: after a successful installation, re-exec new binary not command-not-found. Fixes rh#533554
Should be fixed with this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1795756 I'll make some more fixes to command not found and prep a zero day update. Please can you confirm it's fixed. Thanks.
The build (0.5.4-0.2.20091029git.fc12.x86_64) fixes the bug for me.
I can confirm this as well.
*** Bug 533663 has been marked as a duplicate of this bug. ***
I am seeing this (or a similar issue) with PackageKit-0.5.4-0.1.20091029git.fc12.i686 Attaching gdb gives: (gdb) where #0 0x00303416 in __kernel_vsyscall () #1 0x00ad1913 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x00a70bdb in _IO_new_file_underflow (fp=<value optimized out>) at fileops.c:598 #3 0x00a727db in _IO_default_uflow (fp=<value optimized out>) at genops.c:440 #4 0x00a73dea in __uflow (fp=<value optimized out>) at genops.c:394 #5 0x00a6d4bc in _IO_getc (fp=<value optimized out>) at getc.c:41 #6 0x0804d360 in getchar () at /usr/include/bits/stdio.h:47 #7 pk_console_getchar_unbuffered () at pk-console-shared.c:83 #8 pk_console_get_prompt () at pk-console-shared.c:110 #9 0x0804c524 in main (argc=2, argv=0xbf8c7ef4) at pk-command-not-found.c:766 The issue seems to be that in frame #7 pk-console-shared.c:83 we have: c = getchar (); [...] return c; that always returns -1 (EOF). And in frame #8 pk-console-shared.c:110 there is the following infinite loop: 108 do { 109 /* get the unbuffered char */ 110 answer = pk_console_getchar_unbuffered (); 111 112 /* positive */ 113 if (answer == 'y' || answer == 'Y') { 114 ret = TRUE; 115 break; 116 } 117 /* negative */ 118 if (answer == 'n' || answer == 'N') 119 break; 120 121 /* default choice */ 122 if (answer == '\n' && defaultyes) { 123 ret = TRUE; 124 break; 125 } 126 if (answer == '\n' && !defaultyes) 127 break; 128 } while (TRUE); answer is always EOF (-1) so we never leave the do-while loop.
Please try PackageKit-0.5.4-0.2.20091029git.fc12
Thanks, I tested PackageKit-command-not-found-0.5.4-0.2.20091029git.fc12.i686 and it looks good to me so far. Can it be pushed to Bodhi please, so that it will be available hopefully in time for the F12 release? (A newline after "Scanning applications.." would be nice.)
ping?
I'm doing a F12 update today, which will be ready by tomorrow.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
PackageKit-0.5.5-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/PackageKit-0.5.5-1.fc12
PackageKit-0.5.5-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update PackageKit'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13033
gnome-packagekit-2.28.3-0.1.20091211git.fc12,kpackagekit-0.5.2-1.fc12,PackageKit-0.5.5-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gnome-packagekit-2.28.3-0.1.20091211git.fc12,kpackagekit-0.5.2-1.fc12,PackageKit-0.5.5-1.fc12
gnome-packagekit-2.28.3-0.1.20091211git.fc12, kpackagekit-0.5.2-1.fc12, PackageKit-0.5.5-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-packagekit kpackagekit PackageKit'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13421
gnome-packagekit-2.28.3-0.1.20091211git.fc12, kpackagekit-0.5.2-1.fc12, PackageKit-0.5.5-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.