search

end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Get rid of PID 0 process on Linux #144

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
As discussed here:
http://code.google.com/p/psutil/issues/detail?id=140#c4
...we're currently providing a PID 0 on Linux, which actually does not exist:

>>> 0 in psutil.get_pid_list()
True
>>> psutil.Process(0)
<psutil.Process (pid=0, name='sched') at 140504839398032>
>>> 

At the beginning of development we hard-coded this behavior in _pslinux.py for 
conformity with other platform implementations but on a second thought I'm not 
sure it's been a good idea. It's not a big deal in pratical terms but a user 
willing to get the number of currently running processes would get an erroneous 
value.
My vote is to get rid of all 0 pid code in the next version.
Jay, what do you think?

Original issue reported on code.google.com by g.rodola on 27 Dec 2010 at 4:08

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 27 Dec 2010 at 4:08

GoogleCodeExporter commented 9 years ago 
I personally think we should keep it, but document it since it provides a way 
to get information for the "kernel" process even before init, and it fits 
nicely with other platforms. As long as it's adequately documented I think we 
should keep it in place.

Original comment by jlo...@gmail.com on 27 Dec 2010 at 7:49

GoogleCodeExporter commented 9 years ago 
> it provides a way to get information for the "kernel" process even before init

What do you mean?
As of now we are "faking" all the return values with bogus data such as [], "", 
or AccessDenied exception.

Original comment by g.rodola on 2 Jul 2011 at 6:21

GoogleCodeExporter commented 9 years ago 
I'd like to move forward with this and figure out what to do.
My previous comment still stands: we're currently faking all the returned info 
for no other reason than to comply with those platforms were pid 0 is an actual 
process pid.

Also, pid 0 is not shown by cmdline tools such as ps, top and iotop, adding 
unnecessary burden in case one wants to clone those tools (see issue 213 - 
iotop clone).

Original comment by g.rodola on 29 Sep 2011 at 11:26

GoogleCodeExporter commented 9 years ago 
That's fine, you can remove it if you want to. I think it makes sense since 
there IS debatably a PID 0 / sched process on Linux, but it's not a critical 
feature.

Original comment by jloden.n...@gmail.com on 30 Sep 2011 at 12:10

GoogleCodeExporter commented 9 years ago 
I've been trying to search info about this and results aren't exhaustive.
AFAICT, ps cannot provide any info:

giampaolo@ubuntu:~$ ps -p 0
ERROR: Process ID out of range.
giampaolo@ubuntu:~$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Sep29 ?        00:00:00 /sbin/init
root         2     0  0 Sep29 ?        00:00:00 [kthreadd]
...

Other than that, even is there is a pid 0, we are not returning any information 
about it aside from an hard coded name ("sched"); this is my real point.

Original comment by g.rodola on 30 Sep 2011 at 8:05

GoogleCodeExporter commented 9 years ago 
> Other than that, even is there is a pid 0, we are not returning any 
information about it 
> aside from an hard coded name ("sched"); this is my real point.

And the boot time of the system as the start time of the process, IIRC. 

Again, it's not a critical feature, we can remove it if you want, I don't think 
anyone will have a problem with it.

Original comment by jlo...@gmail.com on 30 Sep 2011 at 12:24

GoogleCodeExporter commented 9 years ago 
Checked in as r1141.

Original comment by g.rodola on 30 Sep 2011 at 2:55

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 21 Oct 2011 at 11:44

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 21 Oct 2011 at 11:45

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Updated csets after the SVN -> Mercurial migration:
r1141 == revision 9abda73cc8d1

Original comment by g.rodola on 2 Mar 2013 at 11:57