Finding Sleeping Process PID's

[Richard Malafa_1]

We used 'TOP' and other programs from time to time to find out what is
happening. My concern is about the classification "Sleeping". How does 'TOP'
or any other pgm determine whether a process is "sleeping". What does it
check?? I'm interested in find the PID of the program that is sleeping.

Thank You
Richard Malafa

[Neil Gast_1]

The states of all process is kept on the kernel's process table. Tools like
top(1) query the kernel for that information.
I'm not sure why you're concerned about processes that are in a sleep state --
it merely means that the process is waiting for some event or resource.
The top(1) command shows the PID of the process in column 2. I'm not aware of
any other command that will show both the PID and the process state.

MrNeil

[Richard Malafa_1]

Neal
You can find them with the ps -el command.
as you can see it's the second column. I'd love to know how it determines this
because I have a royal headache with a K series machine that is being used for
development. c/c++ pgms. I'm getting anywhere from 300 to 500 sleepers. As
far as I can see this is too much. No, correct me if I'm wrong. Neil, I tried
to write to you but the Lotus Notes returns a no existance note. Write me at
rmalafa@csc.com
Rich


-l Show columns flags, state, uid, pid, ppid, cpu,
intpri, nice, addr, sz, wchan, tty, time, and
comm, in that order.

state The state of the process:

0 Nonexistent
S Sleeping
W Waiting
R Running
I Intermediate
Z Terminated
T Stopped
X Growing

[Alan Riggs_1]

Richard,
At any given time, only one process per CPU can be in a running state. The
majority of the others, given normal operation, will be in sleep state. This
just means they are not actively consuming CPU and have not been terminated,
blocked on I/O, etc. It is not abnormal to have several hundred "sleeping"
processes on a K box.

[Richard Malafa_1]

Alan & Neil,
Yes that is true on the one process at a time (per processor??). Of course I'm
referring to Process Sleep and Wakeup on a Shared Memory Multiprocessor. Some
of these babies will never wake up. But the 'top' and 'ps' lists them as
sleeping. I've had to literally reboot the machine to disengage them. (and
that's the only way I know they're junk).

I think some of these problems are inhertited from the early implementations.
i.e. UNIX adapting from the standard uniprocessor scheme to our Multiprocessor
needs.

Anyhow, have either of you seen code that tells me how HP (or Anyone else)
determines that a process is sleeping?? Is it a Lock?? The lock attribute??
Something else?? Did I miss an example somewhere in the MeasureWare software??
btw I've had good results with ps -el | grep S That's a capital S I
basically need another test to tell me if it is truly dead.

Thanks Guys.
Rich
P.S. Also: all these "vx_inactive_th" entries with ps.. What's your opinion..??

[Alan Riggs_1]

I am not certain that I am understanding exactly what you need. If your
concern is with shared memory processes not cleaning up properly, then ipcs -ma
will show you the shared memory segments (ipcs -a will also show semaphores and
queues). I would think the columns you would be most interested are:
MODE First entry may show S,R,D -- indicating segment is waiting on a
send or receive, or that it has been deleted but is waiting for a process to
detach from it.
CPID PID of creating process
LPID PID or last process to access segment
ATIME last time segment was attached to
DTIME last time process was detached from

ipcrm -m will allow you to clean up shared memory segments which are no longer
valid.

If you are finding zombie processes, then you are correct that they can only be
removed with a reboot. They are also symptomatic of other processes not
cleaning up after themselves on shutdown, and that is where you need to focus
to eliminate them.

The vx_inactive_thread processes are used by JFS and are required if you are
using vxfs file systems. If you are not using JFS, then you can eliminate the
vx_* processes by removing the vxbase driver from your kernel.