os.kill not raising an OSError, however I do not see the given pid running

Question

On my ubuntu server I run the following command:

python -c 'import os; os.kill(5555, 0)'

This is done so that I can see if pid 5555 is running. From my understanding this should raise an OSError if the pid is not running. This is not raising an OSError for me which means it should be a running process. However when I run:

ps aux | grep 5555

I see no process running with that pid. This also happens on several other pids in that general range, but it does not happen with say 555 or 55555.

Does anyone have any insight as to why os.kill would not raise an OSError like it is expected to?

Note: this is running under python 2.5.1.

Answer 1

Try installing htop (sudo apt-get install htop), it sometimes displays process that ps doesn't.

Answer 2

Maybe it's a bug in 2.5? On 2.6.4 I get:

gruszczy@gruszczy-laptop:~$ python -c 'import os; os.kill(5555, 0)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 3] No such process

I believe, there is a bug report for this:

http://mail.python.org/pipermail/new-bugs-announce/2009-February/004222.html

Answer 3

I don't know why that OSError is not raised in some cases, but it's important to note that there is a max pid value on linux and unix based OS:

$> cat /proc/sys/kernel/pid_max
32768

Answer 4

Under linux, each process and each thread have a different pid. os.kill doesn't care whether you have a thread pid, or a task pid, however ps doesn't normally show the thread pids.

For instance on my machine the process with PID 8502 is running threads which you can see like this

$ ls /proc/8502/task/
8502  8503  8504  8505  8506  8507  8511  8512  8514  8659

Note that 8503 doesn't appear in the process list

$ ps aux | grep [8]503
$

However using some more ps arguments you can see it

$ ps -eLf | grep [8]503
ncw       8502     1  8503  0   10 10:00 ?        00:00:00 /usr/lib/virtualbox/VBoxSVC --automate

(Grepping for [8]503 means that the grep won't show up - it's an old unix trick!)

Now lets see if it is alive or not

$ python
Python 2.6.4 (r264:75706, Nov  2 2009, 14:44:17)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Loaded customisations from '/home/ncw/.pystartup'
>>> import os
>>> os.kill(8503, 0)
>>>

This duplicates your problem.

I think if you do

ls /proc/*/task/5555

or

ps -eLf | grep [5]555

You will see the culprit thread.