Bug 533554

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.