Linux: Process.get_cpu_times and friends succeed on zombie processes

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Create a zombie process, for example by running subprocess.Popen(['ls']) and 
not calling .wait().
2. Attach a psutil.Process to the pid of the zombie process
3. Call a method like Process.get_cpu_times or Process.get_memory_info--the 
calls succeed but return zeros

What is the expected output?

Based on the docs, anyways, I would expect a NoSuchProcess exception to be 
raised even for zombie processes.

What do you see instead?

The calls succeed and return zeros.

What version of psutil are you using? What Python version?

psutil: 1.2.1
Python: 2.7.x, 3.3.x

On what operating system? Is it 32bit or 64bit version?

RHEL6 64-bit

Please provide any additional information below.

I'm pretty sure this is just because on Linux most of these methods rely on 
reading from /proc/<pid>/stat[m] and friends, which still exist for zombie 
processes.  Most of them look for an EnvironmentError to be raised before 
reraising as a NoSuchProcess, but as long as reading from /proc succeeds that 
doesn't happen.  Methods that read from /proc/ should check that the process's 
status is not 'Z'.  I'll see if I can provide a patch if I have time later.

Original issue reported on code.google.com by erik.m.b...@gmail.com on 23 Jan 2014 at 5:16

[GoogleCodeExporter]

The assumption of expecting NoSuchProcess for a zombie processes is wrong IMO.

To say one, you are able to figure out the status of a zombie process at any 
time *exactly because it is not gone yet* and as such I don't see why it should 
be treated differently than any other process.

That happens not because psutil relies on /proc. Even if you'll call 
p.get_cpu_affinity() or p.get_ionice() you won't get NSP and those calls derive 
from actual kernel (C) function calls, they don't read a file in /proc.

Last but not least, even if checking process status for every call were the 
right thing to do (and I believe it is not) we would introduce a big slowdown 
just to avoid an incorrect "null" 0.0 value and that's not a good deal IMO. 

Original comment by g.rodola on 23 Jan 2014 at 6:26

• Added labels: OpSys-Linux

[GoogleCodeExporter]

I agree, it could get expensive fast; I didn't test all the different methods 
on Process to see if any do raise NSP.

I was basing the assumption that it *should* raise an exception from the docs 
for NoSuchProcess which read "Raised when no process with the given PID is 
found in the current process list or when a process no longer exists (zombie)."

Of course "process no longer exists" and "process is a zombie" are two very 
different things, so this wording is a bit confusing anyways.  So if nothing 
else maybe a documentation fix is in order?

And that being the case, what *would* be the recommended approach to checking 
the process status in, say, a monitor loop?  Just check the status once, before 
making other Process method calls?

Original comment by erik.m.b...@gmail.com on 23 Jan 2014 at 6:33

[GoogleCodeExporter]

Ah! Yes I agree the wording is incorrect and should be fixed (sorry).
As for your second question: I would recommend checking process status before 
anything else as in:

for p in psutil.process_iter():
    try:
        status = p.status
        if status != psutil.STATUS_ZOMBIE:
            ...
    except psutil.NoSuchProcess:
        pass

Original comment by g.rodola on 23 Jan 2014 at 6:46

[GoogleCodeExporter]

Okay, great--that's what I think we'll end up doing in psrecord, where this 
came up: https://github.com/astrofrog/psrecord/pull/7

It was just odd that this wasn't noticed until I tried running it on Linux.  
But if that wasn't the expected behavior to begin with that's fine by me so 
long as the docs are cleared up :)

Original comment by erik.m.b...@gmail.com on 23 Jan 2014 at 7:39

[GoogleCodeExporter]

This is now fixed in the new upcoming doc:
http://psutil.readthedocs.org/en/latest/#psutil.NoSuchProcess
Closing this out.

Original comment by g.rodola on 1 Feb 2014 at 6:32

• Changed state: Fixed
• Added labels: Documentation
• Removed labels: OpSys-Linux