On Thu, 2009-03-05 at 10:42 +0000, Mark Rogers wrote:
Mark Rogers wrote:
Is there anything I can do to find out where it's stuck to fix it? I haven't killed the process yet (although I think I'll have to pause it to get some CPU back).
Curiouser and curiouser....
I went to bring the job into the foreground so that I could pause (Ctrl-Z) it [*]
$ jobs [1]+ Stopped sudo updatedb (wd: ~) $ fg 1 sudo updatedb (wd: ~) [sudo] password for mark:So it looks like I must have run sudo updatedb & .. and sudo needed my password, which it couldn't get in the background. Understandable in itself, but why would it need such a high cpu level to do nothing?
I have seen cases in the past where a program prompts for some kind of input, like a password, and it has been written so if you simply press Return/Enter it re-prints the prompt and waits for further input. Sometimes the writer has failed to detect the difference between a blank line and EOF (or a read error) in which case it can do this.
In this case though the odd thing is how a program that has been stopped cam use CPU. If a process is stopped it should not use CPU. Is the CPU usage user or system? What kernel version are you using?
[*] Incidentally, is there an equivalent to fg for pausing a background job?
kill -STOP %1
But then in you quote above it already shows as stopped.
Regards, Steve.