An exception should be raised when passing a non-existent PID to psutil.Process()

[giampaolo]

From [email protected] on February 17, 2009 02:20:46

What steps will reproduce the problem?  
>>> p = psutil.Process(3124234545)
>>> 

There's no such process with PID 3124234545 but no exception is raised when
Process() gets instantiated.
Various types of exceptions may occur later when we start to access process
properties, for example:

>>> p.name
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "psutil/psutil.py", line 69, in name
    self.deproxy()
  File "psutil/psutil.py", line 58, in deproxy
    self._procinfo = _platform_impl.get_process_info(self._procinfo.pid)
  File "psutil/_pslinux.py", line 39, in get_process_info
    f = open("/proc/&#37;s/stat" &#37;pid)
IOError: [Errno 2] No such file or directory: '/proc/3124234545/stat'


It would make sense checking if the PID exists at least in the Process
class constructor and eventually also in other parts of the code.

Original issue: http://code.google.com/p/psutil/issues/detail?id=12

[giampaolo]

From [email protected] on February 17, 2009 09:14:30

I think this exception only occurs on Linux - other platforms would end up 
None values for everything except PID when calling 
Regardless, probably not desired behavior, I think a NoSuchProcess exception or
something similar makes more sense.

We can check if the PID exists by just doing a "if pid not in
_platform_impl.get_pid_list()" in the constructor. Maybe it makes sense to 
pid_exists(pid) method for reuse also. It'd be nice if we didn't have to incur 
overhead every time we create a Process object, but I don't see another way to 

We should probably also consider what to do in the event the PID disappears 
create the Process object. For example: 

    myProc = Process(1234)
    time.sleep(5)         # time-consuming task, process dies in meantime
    print myProc.name 

Because the name property will *then* trigger a deproxy() and calling
get_process_info() we'll basically end up with a bunch of None values for name, 
cmdline, etc. Maybe get_process_info() should also raise an exception if the 
longer exists/is defunct for whatever reason. If they've already deproxied and 
get_process_info() successfully then I would say leave the values alone.

Finally, I can see a case for a is_running() method to the Process object. That 
users can check on a process if needed. After the Process object has been 
if the process dies out there's currently no way to tell unless you were to 
check for the PID in the process list.

[giampaolo]

From [email protected] on February 17, 2009 21:54:00

Since our Linux implementation relies uniquely on reading files in /proc a 
*could* be "wrapping" every _pslinux.Impl() method into an implicit try/except 
by using a decorator and check for IOError "No such file" exceptions.
When such an event occurs we assume it's because the process has died in the 
and raise NoSuchProcess instead.

The patch in attachment does that.
I called the decorator "prevent_zombie" since I didn't find anything better. =)

If this is what we want, using a decorator could be both practical and elegant 
I don't know if replicating this same behavior on other platforms relying on C
extension would be possible.
Could someone clarify me this point?

Attachment: psutil.patch

[giampaolo]

From [email protected] on February 18, 2009 09:16:50

Implemented NoSuchProcess exception in r124 As far as using a decorator, it 
However, I think it's a bad idea to have a case where a NoSuchObject exception 
raised *after* the Process object is created, especially in the middle of a 
call or while accessing one of the properties. 

That being said, our Process object doesn't necessarily have
_platform_impl.get_process_info() called right away, so we need to figure out 
handle it if someone creates the Process object and doesn't trigger deproxy() 
away. In the meantime if the process goes away, then when they finally do 
deproxy() it would fail to fetch the process information. I'm loathe to just 
trigger a NoSuchObject exception all of the sudden when the user tries to 
of the properties, but I don't at the moment have an alternative suggestion. 
need to think about this and discuss internally before we implement something, 
make it consistent across platforms. Perhaps it would be best to move this 
to a separate issue # and close out this one since the exception has been 
non-existent PID in the constructor.

Status: Accepted

[giampaolo]

From [email protected] on February 18, 2009 10:29:42

We can discuss about what to do if the process dies before we fill out the 
info in Issue 15 .
I'm closing out this one as "Fixed".

Status: Fixed
Owner: jloden
Labels: Milestone-0.1.1 Component-Library

[giampaolo]

From [email protected] on February 23, 2009 09:49:02

Labels: -Component-Library

[giampaolo]

From g.rodola on March 02, 2013 03:39:40

Updated csets after the SVN -> Mercurial migration: r124 == revision