YES process using 99% utilization.

[Silver_1]

Hi,

Here is the top output.

System: hp00001 Thu Jan 26 13:01:25 2006
Load averages: 1.64, 1.40, 1.25
704 processes: 678 sleeping, 24 running, 1 stopped, 1 zombie
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 1.28 51.2% 0.0% 25.4% 23.4% 0.0% 0.0% 0.0% 0.0%
1 1.65 77.0% 0.0% 14.8% 8.3% 0.0% 0.0% 0.0% 0.0%
2 1.84 55.3% 0.0% 32.3% 12.4% 0.0% 0.0% 0.0% 0.0%
3 1.77 64.2% 0.0% 25.8% 10.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 1.64 61.9% 0.0% 24.7% 13.4% 0.0% 0.0% 0.0% 0.0%

Memory: 7536408K (1574760K) real, 8322076K (1965248K) virtual, 3184220K free Page# 1/16

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 5536 root 241 20 1716K 152K run 674:04 91.35 91.20 yes


What can be the reason ?

Thanks.

[Patrick Wallek]

Do a 'ps -ef |grep 5536' and look for the Parent procedd id of the 'yes' process.

It may be that someone was using 'yes' in a script and it ran away from them.

Do a 'man yes' for more details on the yes command.

[James R. Ferguson]

Hi:

Yes. The 'yes' command infinitely produces output of "yes". It is used to provide responses in a non-interactive environment.
It is stopped by killing it or otherwise sending it an interrupt.

See the manpages for more information.

Regards!

...JRF...

[Silver_1]

root 9752 9710 1 13:09:25 pts/4 0:00 grep 5536
root 5536 1 255 23:49:34 ? 681:43 /usr/bin/yes

[Chan 007]

Type

file /usr/bin/yes.

if that is a ascii/awk just cat that file and see what is that script.

Else, kill the process and mv that file as yes.org or so.

Chan

[Patrick Wallek]

Killing that process is probably reasonable.

Moving /usr/bin/yes to something else is not. If you can find out who/what invoked it (probably a big challenge at this point) you can caution them on its use.

[Indrajit_1]

Hi;

do ..

#ps -ef |grep 5536

see the output. u can see what process running..
do..
#finger

u can find the actual user(owner) of this process. Inform him.if u get the permission, u can kill the process

#kill 5536


cheers
indrajit

[Silver_1]

Friends, i killed 2-3 yes processes.

I kept one for troubleshooting.

As said, it is difficult to dig the source.

------------------------
root@hp00001:/var/opt/perf# finger 5536
Login name: 5536 In real life: ???
root@hp00001:/var/opt/perf#

[Silver_1]

the finger command i have given earlier was the pid...sorry.

The user is root who owns the pid..

[Patrick Wallek · Accepted solution]

Well, since the PPID is 1, that may mean that whatever called 'yes' has now finished or was killed itself or something and the 'yes' process got init assigned as its parent.

At this point, I can't think of a whole lot to do to see what called yes initially.

[Bill Hassell]

Because the yes process is now owned by init, the parent may have been killed with -9 (a bad thing to do) or the parent that called yes crashed or became disconnected from it's parent.

Normally, scripts and processes that call yes only need the program for a few iterations and then the program is terminated. Somehow, the calling program left the program running into a bit bucket. For example:

yes > /dev/null 2>&1

will run yes forever and it will consume 100% of one CPU. So you'll probably have to watch the start time for a runaway yes and try to correlate it with process schedules. Since yes is often used in scripts, some grep's through cron jobs and other scripts may narrow down the choices.