Closed GoogleCodeExporter closed 8 years ago
System uptime is already retrieved across all platforms because that's the
value we return for PID 0 (aka the "system process") create time property:
>>> psutil.Process(0).create_time
1291747130.0
As you pointed out it is not publicly available in terms of current API though.
Maybe it makes sense to expose it as a psutil.UPTIME constant.
I don't think it is worth to provide an extra function to calculate the time
delta since you would easily get it by just doing:
>>> delta = time.time() - psutil.UPTIME
Original comment by g.rodola
on 8 Dec 2010 at 1:26
The name UPTIME seems a bit confusing. I'd call it BOOT_TIME or something
similar.
As for the feature psutil.Process(0) returns the system process: I didn't know
about the feature and I can't find it in the documentation, too. I'd even
expected that psutil.Process(0) returns the information of the *current*
process rather than the system. Some system APIs use 0 as an alias for the pid
of the current process.
I agree that it's simple to get the uptime once once a developer knows about
this feature. However a simple function get_system_load makes it really obvious
that it's even possible with psutil. ;)
Original comment by tiran79
on 8 Dec 2010 at 1:44
> The name UPTIME seems a bit confusing. I'd call it BOOT_TIME or something
similar.
Yes, it's probably better.
> As for the feature psutil.Process(0) returns the system process: I didn't
know
> about the feature and I can't find it in the documentation, too. I'd even
expected
> that psutil.Process(0) returns the information of the *current* process
rather than
> the system. Some system APIs use 0 as an alias for the pid of the current
process.
PID 0 is a legal PID on Windows, OSX and FreeBSD, hence it would be just wrong
making it an alias for current process pid.
It is true that there's no such thing as "PID 0" on Linux though.
When we wrote the first psutil draft 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.
> However a simple function get_system_load makes it really obvious that it's
> even possible with psutil. ;)
I guess you meant get_system_uptime() here.
In this case I prefer a constant instead, since system boot time is something
which does not change over time (just like psutil.TOTAL_PHYMEM).
Original comment by g.rodola
on 8 Dec 2010 at 2:08
> PID 0 is a legal PID on Windows, OSX and FreeBSD, hence it would be just
wrong making it an alias for current process pid.
> It is true that there's no such thing as "PID 0" on Linux though.
I wasn't aware that PID 0 are legal on Windows and BSDish platforms. On Linux
PID 0 has special meaning for some syscalls. For example kill(0, SIG) sends the
signal to all processes in the current process group. I know that I've used it
as an alternative to getpid(), but I can't remember the context right now.
I didn't want to convince you to use 0 this way. I was merely trying to explain
my (wrong) expectation.
> I guess you meant get_system_uptime() here.
Yeah, sorry. I've confused both feature requests for a second.
> In this case I prefer a constant instead, since system boot time is something
which does not change over time (just like psutil.TOTAL_PHYMEM).
You have convinced me. Make it so! :)
About not changing TOTAL_PHYMEM, IIRC there are plans regarding virtualization
to change the amount of physical memory of a running guest. The assumption of a
fixed TOTAL_PHYSMEM may become wrong in the future.
Original comment by tiran79
on 8 Dec 2010 at 2:23
> About not changing TOTAL_PHYMEM, IIRC there are plans regarding virtualization
> to change the amount of physical memory of a running guest. The assumption
> of a fixed TOTAL_PHYSMEM may become wrong in the future.
That's an interesting observation... We can cross that bridge when we get to it
I guess, but thanks for the tip!
Original comment by jlo...@gmail.com
on 8 Dec 2010 at 3:42
Implemented on Linux and FreeBSD in r847 and r848.
Original comment by g.rodola
on 10 Dec 2010 at 10:08
Sorry, r846 and r847.
Original comment by g.rodola
on 10 Dec 2010 at 10:09
Implemented on Windows in r848.
Original comment by g.rodola
on 10 Dec 2010 at 10:19
Original comment by g.rodola
on 10 Dec 2010 at 10:23
Implemented on OSX in r915.
Original comment by g.rodola
on 17 Feb 2011 at 2:17
Original comment by g.rodola
on 17 Feb 2011 at 2:17
Original comment by g.rodola
on 20 Mar 2011 at 9:55
[deleted comment]
Updated csets after the SVN -> Mercurial migration:
r846 == revision 4153e742a98b
r847 == revision ed93d5e8d12b
r848 == revision 76fde21cdd2e
r915 == revision a5c46a7300dd
Original comment by g.rodola
on 2 Mar 2013 at 11:57
Original issue reported on code.google.com by
tiran79
on 8 Dec 2010 at 1:12