Created attachment 453988 [details] Strace of bash and children looking for a non-existant command with timestamps. Description of problem: Since F13 PackageKit-command-not-found has been shipped in the default install on the x86_64 DVD. I'd consider this problem resolved if it were simply removed… but I'm guessing that won't happen. On a stock out-of-the box install PackageKit-command-not-found on a fast laptop with a SSD causes multiple second delays for incorrect commands. The delays are infuriating and inexplicable— The first time I hit this I thought my drive might be failing until I straced bash. Upon complaining in #fedora-devel on freenode around the time of the F13 release I was informed that the inclusion of this package in the default install was a mistake. Apparently not. I remove it immediately on install but I'm concerned about the quality of the fedora experience for everyone who hasn't gone through the trouble of finding and removing it. I've attached a strace from a bash process trying to execute a missing command. In this case the whole operation takes 2.23 seconds. As you can see it's doing a rather brute-force search for some 25 different case foldings and permutations (many of which look fairly useless) in both /usr/bin and /usr/sbin, and each one it checks twice once for existence once for execute bit, which is wasteful— but that doesn't appear to be the the bulk of the time. It looks like it's spending a lot of time communing with the package manager over a socket. I'd be glad to test attempted fixes— but my own solution is simply to remove it. Version-Release number of selected component (if applicable): PackageKit-command-not-found-0.6.9-4.fc14.x86_64 How reproducible: Steps to Reproduce: 1. Install F14 x86_64 DVD 2. Try to use the command line 3. Forget why you're using a dual core 64 bit system— the C64 was more responsive. Actual results: CLI is annoyingly slow. Expected results: CLI is fast.
(In reply to comment #0) > As you can see it's doing a rather brute-force search for some 25 different > case foldings and permutations (many of which look fairly useless) in both > /usr/bin and /usr/sbin, and each one it checks twice once for existence once > for execute bit, which is wasteful— but that doesn't appear to be the the bulk > of the time. It looks like it's spending a lot of time communing with the > package manager over a socket. The actual searching takes a few ms. It's asking PackageKit to send us the list of packages that provide the list which is agonizingly slow. The reason that this is slow, is that PackageKit forks yum, which then checks if the repodata is up to date. This is what takes the time, as yum connects to the network and performs checksums on all the data files. > I'd be glad to test attempted fixes— but my own solution is simply to remove > it. Have a look in /etc/PackageKit/CommandNotFound.conf and you can edit all the different options of what is done. Be also sure to have the latest version of PackageKit installed as this has a few nice speed fixes for CNF. Note, in the long term I'll be switching SearchFile to use zif directly, rather than yum, as we can make zif operate with a cache and return results in a few ms. If you want to try this, try installing rawhide in a VM, and edit /etc/PackageKit/Yum.conf and add ";search-file" to the UseZif= line. I agree that using yum for each CNF is slow, but we're doing something about it. If you can test this and report success, then maybe we can backport the functionality back into F14. Thanks. Richard.
Perhaps its worth mentioning that I recently installed F14 on a system on a network that didn't have internet access and CommandNotFound seemed to never return (I let it run 30 seconds or so). I know there is some timeout handling but it appears that it doesn't work in all cases. I'll give zif a go on some systems and report back.
Hi, I've just run into this on F14 x86_64. A 2 second delay because of a simple typo is really irritating. I set 'SoftwareSourceSearch=false' in CommandNotFound.conf which removes the delay. regards Richard
(In reply to comment #3) > Hi, > I've just run into this on F14 x86_64. A 2 second delay because of a simple > typo is really irritating. > > I set 'SoftwareSourceSearch=false' in CommandNotFound.conf > which removes the delay. Maybe that would be the sanest default with the current state of package searching affairs, and switch back to true once zif is on. Is this something we could get into an update?
I think the most sensible thing is to not install this package by default until the speed issue is fixed. Those who know why they get delays (e.g. you, me, others) remove this package immediately, whereas others (who might be newer to Linux) get a confusing response to a command not found in the form of a delay and list of possible packages they could install. It seems to me that this package has a use to those who want it, but caters neither to very experienced users nor very beginning users.
R.H., Since you are overseer of this PackageKit feature I was going to contact you, but then I saw this thread. I just wanted to chime in at how, yes, infuriating this delay is. I intended to upgrade to Fedora 14, but the experience of several annoying things so far has me starting to consider other distros. I'm very command line oriented because I feel it is a much faster means of working in many instances. This delay only slows me down. Sometimes after a couple seconds, the search times out and indicates "Cancelling search, takes too long" and even that extra text is disorienting. I'm don't think I even want such a feature because I can quickly use some other utility to search packages for any missing commands for the occasional time I'd need it. (And if I happen to not have authentication rights, what's the point? I'd have to ask someone else to install the command.) Searching the executable tree is enough. Right now I'm trying to figure out how to disable this. If the developers feel this is a good feature, perhaps have a simple means of turning it off indefinitely upon launching a terminal window. (My initial reaction was to search under "preferences".)
(In reply to comment #6) > Right now I'm trying to figure out how to disable this. Either edit /etc/PackageKit/CommandNotFound.conf or just remove the PackageKit-command-not-found package. Richard.
I removed the PackageKit-command-not-found package and like the response. Thanks.
I use the command line almost exclusively - I've also found this stalling command-not-found feature very annoying, and have spent some time tracking the reason down to PackageKit-command-not-found, which is now uninstalled from my Fodora 14 machine. I'd put in a vote to remove it from the default install - it might be of use to a CLI beginner, but the whole ethos and design of the command line is for 'power users', and not beginners. It's an interesting idea, but in addition to the unacceptable pauses, this feature doesn't fit in elegantly to the CLI IMHO.
This is still painfully slow in Fedora 17 Beta, and still installed by default in the x86_64 DVD install.
What I found to fix this is just modify this line in /etc/PackageKit/CommandNotFound.conf: # Controls how long we should allow the user to wait when searching for # additional packages. # This can be set to very small numbers to avoid distracting the user, although # some entries may not be found if the caches need refreshing or metadata # downloading. # # Value is the number of milliseconds to allow. # # default=2000 MaxSearchTime=250 I noticed no big difference in it not finding a command and very rarely had that issue where it couldn't find it. It is really fast now when I typo a wrong command. I am running F16 with kernel 3.3.4.x.
F17 still has this problem rpm -e PackageKit-command-not-found cures the problem
PackageKit-command-not-found is not use yum cache and searching all names from the network. This process can be very very slow. In my F17, searching for 'emacs'occurs within 10 seconds. If you want to accelerate your bash - set MaxSearchTime=250 in /etc/PackageKit/CommandNotFound.conf. If you want to make this module operational - set MaxSearchTime=15000 and PackageKit-command-not-found will work, but slowly.
(In reply to comment #13) > PackageKit-command-not-found is not use yum cache and searching all names > from > the network. This process can be very very slow. In my F17, searching for > 'emacs'occurs within 10 seconds. Does this means it sends the command on the network in plaintext? This is a security/privacy issue, as people may (for example) accidentally type their password at the prompt. (I've set SoftwareSourceSearch=false after seeing this bug)
I agree, this package should be uninstalled by default until speed problems are resolved. Currently, it hampers the whole command line experience in exchange for such a minor feature. Couple of seconds of delay every time you make a typo is just plain unacceptable. It is nice that this feature is being developed since it can be useful for some people, but it just should not be on by default, at least for now.
Working on a fix now. I debugged this issue (with the help of Richard) and found that the reason for the horrible slowness is simply yum not being fast enough. The fix will simply disable packagekit-command-not-found package search functionality in case the backend used is yum.
*** Bug 800727 has been marked as a duplicate of this bug. ***
*** Bug 860180 has been marked as a duplicate of this bug. ***
I've merged Elads patch to PackageKit git master. They'll be a new release available in the next couple of weeks (certainly before F18): commit f3254d2e7a263512d838c15d75bdabf20a551b6e Author: Elad Alfassa <elad> Date: Tue Nov 6 16:38:51 2012 +0000 cnf: Don't search for packages if backend is known to be too slow Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643778 Signed-off-by: Richard Hughes <richard> This does mean that if you use the yum backend (the default in Fedora) then the remote searching is disabled, but any other backend (smart, zif, aptcc, etc) can return results in less than 1500ms and thus works fine. I think this is a much better way of fixing the issue, so thanks to Elad for working on it. Richard.
(In reply to Marius Bjørnstad from comment #14) > (In reply to comment #13) > > PackageKit-command-not-found is not use yum cache and searching all names > > from > > the network. This process can be very very slow. In my F17, searching for > > 'emacs'occurs within 10 seconds. > > Does this means it sends the command on the network in plaintext? This is a > security/privacy issue, as people may (for example) accidentally type their > password at the prompt. (I've set SoftwareSourceSearch=false after seeing > this bug) Is this a correct understanding of what this does when it's installed and working?
No, it is not. No personal data is transmitted over the network. The file list metadata archive is downloaded from the mirrors of each repository, and then PacakgeKit performs a search on the downloaded data. You have nothing to worry about.