search

end18 / psutil

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

Expose private _UPTIME as public psutil.BOOT_TIME constant #140

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
psutil already has information for the system's uptime / boot time on Linux and 
Windows. How about adding an new API function that returns the difference 
between boot time and now as timedelta? It's a low hanging fruit.

I don't know if the information is easily available on OSX and BSD. But you 
could parse the output of the "uptime" command and retrieve both uptime and 
load average together. (See my other feature request)

Original issue reported on code.google.com by tiran79 on 8 Dec 2010 at 1:12

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
Implemented on Linux and FreeBSD in r847 and r848.

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

GoogleCodeExporter commented 9 years ago 
Sorry, r846 and r847.

Original comment by g.rodola on 10 Dec 2010 at 10:09

GoogleCodeExporter commented 9 years ago 
Implemented on Windows in r848.

Original comment by g.rodola on 10 Dec 2010 at 10:19

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 10 Dec 2010 at 10:23

GoogleCodeExporter commented 9 years ago 
Implemented on OSX in r915.

Original comment by g.rodola on 17 Feb 2011 at 2:17

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 17 Feb 2011 at 2:17

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 20 Mar 2011 at 9:55

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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