Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 602841 - PackageKit Command Not Found feature hangs shell
PackageKit Command Not Found feature hangs shell
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-10 16:55 EDT by Wolfgang Denk
Modified: 2010-07-07 13:44 EDT (History)
5 users (show)

See Also:
Fixed In Version: PackageKit-0.6.6-1.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-07 13:44:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wolfgang Denk 2010-06-10 16:55:29 EDT
Description of problem:

The PackageKit Command Not Found feature may be nice for newbies, but can be extremely confusing as well. For example, it can (apparently) hang your shell.
In my case, I was trying to run a "script" command; it printed:

$ script /tmp/conslog
Script started, file is /tmp/conslog
Command not found. ^C
Command not found. ^C
Command not found. ^C
Command not found. ^C
...

Then it would hang there, the prompt after the "Command not found. "; trying to break out of it using ^C did not work, I hang in an endless loop and had to kill the command from another session.

The reason for the "Command not found." was that some __git_ps1 was used in my PROMPT_COMMAND, which was not available in the script session.

The reason for the hang was that I had a "yum update" running, which took a long time, and which blocked PackageKit access.

I think this needs at least some timeout handling, and failure detection so a scenario as above will be prevented, *especially* in situations where the command is called as part of PROMPT_COMMAND or similar.

Version-Release number of selected component (if applicable):

PackageKit-0.6.4-1.fc13.i686

How reproducible:

Always.

Steps to Reproduce:
1. Run "yum -y update" (when some updates are available).
2. While yum is running, type a non-existing command, like "foobar".
3.
  
Actual results:

$ foobar
Command not found. 
 * Waiting for package manager lock...
[Waiting here until the "yum update" command has completed.]

Expected results:

- (configurable ?) timeout
- "Command not found" handling performed only on first ocurrence, so endless loops like in my case are prevented

Additional info:
Comment 1 Nicolas Chauvet (kwizart) 2010-06-11 06:23:29 EDT
wrong component
Comment 2 Richard Hughes 2010-06-11 07:13:55 EDT
PackageKit-command-not-found now times out after 5 seconds of not getting the yum lock.
Comment 3 Wolfgang Denk 2010-06-11 07:32:51 EDT
This is definitely much better, but it still leaves the other questions unanswered:

- Does it really make sense to enable such a feature for non-interactive shells like when running commands as part of the PROMPT_COMMAND?

- Does it really make sense to repeat the same lookup over and over? Maybe results could be cached to avoid further lookup?

In my case, having to wait 5 seconds for the next shell prompt is still a PITA - and keep in mind that the average user has no idea what might happen to him. when I ran into this the first time I really didn't know what to look for nor how to avoid it. Or how to disable it.
Comment 4 Richard Hughes 2010-06-11 08:46:38 EDT
(In reply to comment #3)
> - Does it really make sense to enable such a feature for non-interactive shells
> like when running commands as part of the PROMPT_COMMAND?

I didn't think c-n-f was being used for non-interactive shells.

> - Does it really make sense to repeat the same lookup over and over? Maybe
> results could be cached to avoid further lookup?

We have to search yum each time, else we're caching the cache, which isn't really right.

Richard.
Comment 5 Tom Lane 2010-06-20 17:11:35 EDT
I'm observing multi-second delays after "Command not found. " as well, in a pretty nearly stock F-13 installation.  It's *extremely* annoying, and I'd rather turn the help off altogether than put up with that.  Will removing PackageKit do that for me?

I do have one possibly useful bit of information, which is that just now I got this message instead of only a silent hang:

$ iostat 1
Command not found. Failed to search for file: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
$

It wasn't repeatable but a look into /var/log/messages shows something suggestive at about the right time:

Jun 20 17:00:04 rh2 named[1075]: error (network unreachable) resolving 'mirrors.fedoraproject.org/A/IN': 2001:500:f::1#53
Jun 20 17:00:04 rh2 named[1075]: error (network unreachable) resolving 'mirrors.fedoraproject.org/AAAA/IN': 2001:500:e::1#53
Jun 20 17:00:04 rh2 named[1075]: error (network unreachable) resolving 'mirrors.fedoraproject.org/AAAA/IN': 2001:500:48::1#53
Jun 20 17:00:04 rh2 named[1075]: error (network unreachable) resolving 'mirrors.fedoraproject.org/A/IN': 2610:28:200:1::fed0:10#53

Am I to conclude from this that anytime I fat-finger a command, some part of that is going to be communicated externally?  If so, has anyone thought about the security implications of that?  This seems absolutely ill-conceived.
Comment 6 Richard Hughes 2010-06-20 17:17:06 EDT
(In reply to comment #5)
> I'm observing multi-second delays after "Command not found. " as well, in a
> pretty nearly stock F-13 installation.  It's *extremely* annoying, and I'd
> rather turn the help off altogether than put up with that.  Will removing
> PackageKit do that for me?

Well, you could be less dramatic and either remove PackageKit-command-not-found, or edit the preferences in /etc/PackageKit/CommandNotFound.conf

> Am I to conclude from this that anytime I fat-finger a command, some part of
> that is going to be communicated externally?

No, you conclude incorrectly. We just ask yum for the file list, not anything specific.

> If so, has anyone thought about the security implications of that?

Dude, you should know that if there was a hint of a possible security problem, you don't just announce it publicly on a bug. Sheesh.

In this case, I really don't see an issue.
Comment 7 Fedora Update System 2010-07-01 08:00:04 EDT
PackageKit-0.6.6-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/PackageKit-0.6.6-1.fc13
Comment 8 Fedora Update System 2010-07-01 15:01:05 EDT
PackageKit-0.6.6-1.fc13 has been pushed to the Fedora 13 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/PackageKit-0.6.6-1.fc13
Comment 9 Fedora Update System 2010-07-07 13:44:25 EDT
PackageKit-0.6.6-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.