According to top on my desktop: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18387 root 20 0 2876 976 952 R 83.3 0.1 3291:33 sudo
31304 mark 20 0 405m 254m 30m S 8.9 16.8 298:14.33 firefox
5964 root 20 0 190m 80m 13m S 3.3 5.3 142:12.89 Xorg
31994 mark 20 0 62364 24m 10m R 1.3 1.6 1:03.30 gnome-terminal
6196 mark 20 0 46292 10m 8256 S 0.7 0.7 3:28.18 gnome-settings-
6303 mark 20 0 90664 50m 7160 S 0.7 3.3 103:36.48 multiload-apple
11225 mark 20 0 111m 26m 17m S 0.7 1.7 13:11.20 deluge
31092 mark 20 0 2416 1172 876 R 0.7 0.1 0:00.08 top
6243 mark 20 0 21392 5032 4328 S 0.3 0.3 5:03.73 gnome-screensav
So that's 83% for sudo...
I just sat watching it for a while (I only fired up top as the machine was running slow) so although the above is a snapshot it's indicative of a pattern at the moment.
Any suggestions?
Mark Rogers wrote:
According to top on my desktop: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18387 root 20 0 2876 976 952 R 83.3 0.1 3291:33 sudo
Ah, found it: $ ps ax | grep sudo 18387 pts/3 R 3293:11 sudo updatedb 31096 pts/3 R+ 0:00 grep sudo
It seems I kicked off updatedb some time ago (3293 mins is 2+ days of CPU time). Sounds like maybe it's stuck somewhere....
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).
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?
[*] Incidentally, is there an equivalent to fg for pausing a background job?
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.
-
Mark Rogers -
Steve Fosdick