Has anyone else had this problem? Inexplicably, I occassionally (~15% of the time) get a runnaway process called "sh" which ramps CPU ussage up to 100% (whatever it can get). This runs battery life way down, and even heats up the device a bit. Sometimes, there are even multiple instances of this running. It drives me nuts! And I can't kill it. The only way I can stop is to reboot. I'm not a linux ninja, but I generally know my way around well enough. But I don't know how to go about trouble shooting this. Any suggestions? Anyone else having this problem?


Ryan -- ryanwright.org

sh is the standard shell on the N800.

Try "kill -9 PID" where you replace PID by the process ID you can see in the first (I think) column of top.


Simon

Today I had this same problem on os2007he -- after installing privoxy.
Disabling the proxy server seems to have fixed it.
Will post again if the problem returns.

Ryan,

Funny you should notice this, as it happened to me yesterday. I noticed it because the low battery chime was going off. Sure enough, there was a "sh" eating all the available cpu time.

This sh was consuming so much time, that I could not ssh into the n800. Poking around in the xterm, I did the kill -9 as root, and couldn't kill the run away sh, just as you.

I did find that this run away sh was a child process of a second xterm I had running (this is the transparent keyboard osso-xterm). Quitting the second xterm, killed the run away sh, and the problem has not reoccured (yet).

Does anyone have a "real" ps? The ps in busy box doesn't have any of the useful options like showing the parent process which would make troubleshooting this problem much easier.

I hope this helps,

Craig...

I thought I was just me, I have been seeing this also and thought it was in kde. kill -9 xxxx always kills it for me.

btw, I dont have xterm installled.

OK, odd that you mention this today, I have one running right now. I am at work and I am plugged in, so I am not going to kill it, I will try to determine if I can find out whats happening.


Please anyone with some input here is helpfull. Any other ideas about how I can determine what started this process?????





ps | grep 25927

shows

25927 root 628 R -sh


This is what lsof shows about the process

sh 25927 root cwd DIR 254,10 4096 65594 /root
sh 25927 root rtd DIR 254,10 4096 2 /
sh 25927 root txt REG 254,10 238140 98357 /bin/busybox
sh 25927 root mem REG 254,10 97580 114747 /lib/ld-2.3.6.so
sh 25927 root mem REG 254,10 1049484 114782 /lib/libc-2.3.6.so
sh 25927 root mem REG 254,10 23476 114760 /lib/libcrypt-2.3.6.so
sh 25927 root 0u CHR 136,1 3 /dev/pts/1 (deleted)
sh 25927 root 1u CHR 136,1 3 /dev/pts/1 (deleted)
sh 25927 root 2u CHR 136,1 3 /dev/pts/1 (deleted)
sh 25927 root 10u CHR 5,0 1458 /dev/tty

cmon, where are all the guru's

Sorry to be so late. Hopefully you have figured this out by now. But in case you haven't. I have built a real ps and top (which I call rps and rtop, not to conflict with the busybox versions) and put them in a deb for easy installation, which you can find at:
http://www.makikiweb.com/n800/downlo....2.7.armel.deb

By using the real ps, you can see who the parent of the run away process is (the PPID). And perhaps kill that!

Let us know how it goes.

Craig...

[edit 17 Oct] You may need to install 'screen' which supplies the proper terminfo files for xterm (it also installs screen, a interesting, and useful program in itself). Just type as root: apt-get install screen

[not a guru, but I have been around the block]

Yeah I am in scratchbox right now, and I forgot all about it, I was going to compile ps when I got home, darn busybox $#$#@$%... I am grabbing your deb, if it happens again, I will see what we can find out.

Thanks,

Anybody ever figure out what this is?