You are not logged in.
This is a strange one and I can't find anything about it mentioned anywhere so I am starting a new thread.
If I run a non-existent command via ssh to my Arch system it hangs and I can see grep using 100% cpu. It just sits there for a long time.
I am using bash for my shell. The hardware is an Acer Aspire One
Linux gonebook 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 12:06:25 CEST 2010 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
If I run the same command locally, I get an instant "bash: aslkdajdlk: command not found"
It seems to happen with any non-existent command; I first noticed it by mistyping "clear" (lcear)
I don't know if this is an ssh issue (OpenSSH_5.5p1, OpenSSL 1.0.0a 1 Jun 2010), a bash issue (GNU bash, version 4.1.7(2)-release (i686-pc-linux-gnu)), a networking issue (all local LAN, no dropped packets)
I've never seen this happen before in over 10 years of Linux usage.
To re-iterate: I ssh into my Arch system and try to run a non-existent command (catl, asdhjkj, blah) you name it, and grep shows up in top maxed out at 99/100% cpu usage
8394 goner 20 0 3852 944 652 R 100 0.1 0:12.15 grep
And then after a while (almost exactly 30 seconds) it says
bash: catl: command not found
If I "time" the incorrect command I get:
real 0m30.347s
user 0m29.775s
sys 0m0.480sreal 0m30.268s
user 0m29.818s
sys 0m0.393s
here is my /etc/hosts file:
#
# /etc/hosts: static lookup table for host names
#
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost gonebook
# End of file
I discovered this while trying to debug slow ping times on my router. I don't understand why grep becomes involved in all of this.
I can't say enough good things about Arch, but this one's got me stumped.
Offline
I suspect that grep is responsible for searching for the "fake" command. Does it constantly stay at 100%, even after it tells you the command isn't found, or does it go down afterwords?
You may just have to kill grep every time you mis-type.
Offline
And that cpu of your isn't exactly a powerful one.
Offline
karol: This doesn't happen when the bad command is run locally, so it's not a CPU issue.
transmition: The grep process goes away after the "command not found" message. Again, it works fine locally; no hang, no delay. Only when run via ssh does this strangeness occur.
There's no way I'm going to
kill -9 `pidof grep`
every time I accidentally type a command wrong.
Offline
> karol: This doesn't happen when the bad command is run locally, so it's not a CPU issue.
Maybe your ssh prompt runs grep (don't ask me why)?
Offline