Re: psutil.boot_time() ... doesn't ?
Dennis, > However -- manually changing date/time is not going to illustrate this. > ANY change made to date/time will reflect a change in UTC time. It turns out that the get_uptime() does /not/ calculate the boottime from the current clock minus the uptime. Its a seconds-since-epoch (absolute!) value written into the /proc/stat file , *which gets fricking changed when you change the date/time*. In other words, all our "must be local time related" musings are not worth the paper they where written on. :-) Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Dennis, > Well... If it is the last file written during shutdown, it would be > the "last file system modification time" Yep ... up until the next hours cronjob overwriting it ... Currently I've got a (very) small init.d shellscript which copies the contents of that file into another one - which only gets altered on next boot (could not do it in the fake-hwclock script, as that gets first called when the filesystem is still in read-only mode). > The only time it would not be "last modification time" would be if > the system had the power pulled, and was not shut down cleanly. Only the first hour (not sure if that is clock or uptime ...), than it would be overwritten. I've also thought of letting the fake-hwclock write my file on shutdown too. But a bad shutdown would cause problems there. > Of course, in that situation, one has the potential of having a corrupted > file system -- and anything goes... Yup. And in such a case I do /not/ want to have to remember my programs little quirk ... :-( Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Fri, Nov 8, 2019 at 1:24 AM R.Wieser wrote: > > Chris, > > > Yes, but even if it's not recorded as a timestamp but as an > > uptime counter, that counter can be referenced against the > > current time in UTC. > > Absolutily. Though the keyword here is "can". My "could easily imagine" > considers the other possibility. > > I guess I should sit down sometime and just flip the date back and forward > (in-and-outof DST), and see how the result of psutil.boot_time() compares to > the thanwhile current time. > Yep! Nothing like experimentation! :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Chris, > Yes, but even if it's not recorded as a timestamp but as an > uptime counter, that counter can be referenced against the > current time in UTC. Absolutily. Though the keyword here is "can". My "could easily imagine" considers the other possibility. I guess I should sit down sometime and just flip the date back and forward (in-and-outof DST), and see how the result of psutil.boot_time() compares to the thanwhile current time. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Dennis, > Which is probably... last file system modification time Nope. Its from a file it saves at shutdown, and which gets updated once an hour (I also thought of that one, but the once-an-hour update threw a wrench into it). > There is no way for a freshly booted system to differentiate between [snip] True. But 1) thats not likely the moment I will be looking at the "has the time been updated" 2) The same goes for having NTP (or any other such "wait for it ..." method) update the clock. > Except that "last boot time" is really "booted /n/ minutes ago > from /now/". Than thats the point where we disagree. Boot time is not just a gadget for the user to look and gawk at, it has (or /should/ have) its usages. Like allowing someone to determine which files have been altered since last boot. Besides, all you now get is uptime, just presented differently. :-( > http://man7.org/linux/man-pages/man5/crontab.5.html#EXTENSIONS > > The main concern is just how soon after reboot that @reboot executes. Yup. And in which order the different programs and scripts are ran > https://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/ > has an example with a sleep... Thanks for those links. I'll have a look at them. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Wed, Nov 6, 2019 at 7:54 PM Terry Reedy wrote: > I don't know how much Linux is customized for RP, but last I knew, > Python on RP is MicroPython, not CPython. So I expect OS-related > functions to not necessarily match Linux on a desktop. The default OS on all Raspberry Pi models is Raspbian, a full-blown Debian Linux derivative, which comes with Python 2 and Python 3 installed -- CPython, to be clear. MicroPython was designed for microcontroller boards that are too small to run an OS. Popular boards are the BBC microbit and ESP8266. Those devices don't run Linux. To use MicroPython on them, you install firmware that boots directly into the MicroPython runtime, which includes a REPL. Cheers, Luciano > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On 11/6/19, Chris Angelico wrote: > > Yes, but even if it's not recorded as a timestamp but as an uptime > counter, that counter can be referenced against the current time in > UTC. A DST switch affects the displayed time, but not the internal > definition of "current time" (at least, not on Linux, where the system > clock should be in UTC - the rules are different on Windows, and may > also be different on other Unix-like OSes); Windows timestamps are UTC, but the epoch and base time unit are different from Unix. It uses the number of 100 ns intervals since 1601, instead of the number of seconds since 1970. psutil subtracts the value of GetTickCount64() from GetSystemTimeAsFileTime(), so changing the system time will change the reported boot time. But that's expected behavior. Even the kernel's KeBootTime value gets adjusted to account for the time delta when the system time is updated. Otherwise the system would be inconsistent. That said, the kernel (NT 5+) also also has a KeBootTimeBias value that tracks the net delta of KeBootTime from its original value. What psutil does should suffice, but if we need the kernel's exact boot time, without the expense and complexity of a WMI or perflib query, the native system call is NtQuerySystemInformation: SystemTimeOfDayInformation. This returns a SYSTEM_TIMEOFDAY_INFORMATION record, which includes BootTime and BootTimeBias fields. This query is implemented for internal use only, however. The fields and layout of the record are subject to change in future versions of Windows, so caveat emptor. To date, this record was only modified once, back in NT 5 (2000) to augment it with BootTimeBias and SleepTimeBias fields. -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On 2019-11-06 22:53, Terry Reedy wrote: On 11/6/2019 3:09 PM, R.Wieser wrote: Dennis, Depends upon the OS... My apologies, its Linux (as on a Raspberry Pi). I don't know how much Linux is customized for RP, but last I knew, Python on RP is MicroPython, not CPython. So I expect OS-related functions to not necessarily match Linux on a desktop. MicroPython is for smaller systems. Raspberry Pi has a full Python implementation, as far as I can tell. I have one running Python 3.5 with the regex module installed, the module being downloaded via pip from PyPI and built from source on the RP. No changes were needed to make it work. -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Thu, Nov 7, 2019 at 9:55 AM Terry Reedy wrote: > > On 11/6/2019 3:09 PM, R.Wieser wrote: > > Dennis, > >> Depends upon the OS... > > > > My apologies, its Linux (as on a Raspberry Pi). > > I don't know how much Linux is customized for RP, but last I knew, > Python on RP is MicroPython, not CPython. So I expect OS-related > functions to not necessarily match Linux on a desktop. > Fair point, although in this case, I think the interpreter won't make a difference - the psutil module is pure Python and depends on underlying OS facilities. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On 11/6/2019 3:09 PM, R.Wieser wrote: Dennis, Depends upon the OS... My apologies, its Linux (as on a Raspberry Pi). I don't know how much Linux is customized for RP, but last I knew, Python on RP is MicroPython, not CPython. So I expect OS-related functions to not necessarily match Linux on a desktop. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Thu, Nov 7, 2019 at 7:31 AM R.Wieser wrote: > > Chris, > > > I don't think boot time would be affected by a DST switch, though. > > It should be recorded in UTC. > > The point is, it /isn't/ a recorded constant (at least not on my machine). > Its just dragged around with the clocks current time (as in: current time > minus uptime). And as such I could easily imagine a DST change will cause > the "boot time" to change accordingly. > Yes, but even if it's not recorded as a timestamp but as an uptime counter, that counter can be referenced against the current time in UTC. A DST switch affects the displayed time, but not the internal definition of "current time" (at least, not on Linux, where the system clock should be in UTC - the rules are different on Windows, and may also be different on other Unix-like OSes); if your current UTC time is 1573072926 seconds and your uptime is 7469247.52 seconds, then you can deduce that your system booted at 1565603679, and then convert that to a displayable boot time in whatever timezone you like (for instance, "Mon Aug 12 19:54:39 2019\n" which is what my ctime() returns). A DST switch wouldn't affect any of this, assuming you have the correct tzdata to figure out whether the boot time was on summer or winter time. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Thu, Nov 7, 2019 at 7:21 AM R.Wieser wrote: > > Chris > > > That's possibly because you're looking at psutil, which is a third > > party package. Here's its documentation: > > My info came frome here: > https://www.programcreek.com/python/example/53873/psutil.boot_time > > Looking at example 1 it looks the be the same. Yep, looks like that site probably cribbed the example from the docs, or similar. Your code is fine. > > But I don't know what its definition is, whether it's "current time > > minus uptime" or "timestamp recorded during bootup". It might > > not even be consistent across platforms. > > Oh yoy ! :-\ Yeah... welcome to the wonderful world of cross-platform libraries that depend on different facilities. Different OSes make different promises, and the library has to try to paper over those distinctions and give a consistent result. It's usually fine, but there WILL be edge cases. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Chris, > I don't think boot time would be affected by a DST switch, though. > It should be recorded in UTC. The point is, it /isn't/ a recorded constant (at least not on my machine). Its just dragged around with the clocks current time (as in: current time minus uptime). And as such I could easily imagine a DST change will cause the "boot time" to change accordingly. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Chris > That's possibly because you're looking at psutil, which is a third > party package. Here's its documentation: My info came frome here: https://www.programcreek.com/python/example/53873/psutil.boot_time Looking at example 1 it looks the be the same. > But I don't know what its definition is, whether it's "current time > minus uptime" or "timestamp recorded during bootup". It might > not even be consistent across platforms. Oh yoy ! :-\ Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Thu, Nov 7, 2019 at 7:16 AM R.Wieser wrote: > But granted, on a Raspberry thats a bit of a problem. On the other hand, > just dragging the "last boot time" around by whatever time you now set feels > like fakery. > > Oh man, I can already imagine a CSI plot where someone tries to use as linux > machines boot time as an alibi, but summer time just arrived, causing it to > appear an hour later .. :-) https://www.youtube.com/watch?v=w45QkL9blG4 :) I don't think boot time would be affected by a DST switch, though. It should be recorded in UTC. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Dennis, > Depends upon the OS... My apologies, its Linux (as on a Raspberry Pi). > You can easily look at the code used by psutil :-) I somehow assumed that those where build-in into the language itself. I'll have to take a peek at what else is available there too. > I read somewhere that the kernel calculates the btime from the > current gettimeofday minus the jiffies since boot converted to > seconds. That was also my guess to what happened. > last file system modification time > hardware RTC (if equipped) > NTP update (if networked) > what should your "boot time" be referenced against? The built-in clock ofcourse. :-) But I would not mind if it would be set to some believable time by the fake-hwclock. But granted, on a Raspberry thats a bit of a problem. On the other hand, just dragging the "last boot time" around by whatever time you now set feels like fakery. Oh man, I can already imagine a CSI plot where someone tries to use as linux machines boot time as an alibi, but summer time just arrived, causing it to appear an hour later .. :-) > but that boot time will depend on exactly when the CRON job ran > in relation to the three potential sources of clock time. I was already thinking of something similar (running a script at boot), but also saw such race-time problems. I might edit the fake-hwclock code though. Copying the clocks current date/time after it has just been set (or not, when an RTC is installed) would be enough for my purposes. ... Though I would rather not mess around in/with system files. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Thu, Nov 7, 2019 at 6:11 AM R.Wieser wrote: > > I also tried to google "python BOOT_TIME", but got nowhere (the latter parts > casing was ignored). Hence me posting here. > That's possibly because you're looking at psutil, which is a third party package. Here's its documentation: https://psutil.readthedocs.io/en/latest/#psutil.boot_time But I don't know what its definition is, whether it's "current time minus uptime" or "timestamp recorded during bootup". It might not even be consistent across platforms. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Maxime, > You may want to read PEP 418 which nicely summaries the > different clock available on each platform and their limitations. You mean the CLOCK_REALTIME and CLOCK_MONOTONIC ones ? Yeah, that was what I was looking at :-) > It looks like CLOCK_BOOTTIME is what you want but it is only > available on Linux. While googeling for an explanation and/or solution to the behaviour of psutil.boot_time() I also came across it - and it was marked as depricated, with the above function as its successor. I did try to use it though, but Raspberry Pi's Python3 threw a "no idea what that is" error. :-\ I also tried to google "python BOOT_TIME", but got nowhere (the latter parts casing was ignored). Hence me posting here. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
Hello, You may want to read PEP 418 which nicely summaries the different clock available on each platform and their limitations. It looks like CLOCK_BOOTTIME is what you want but it is only available on Linux. Regards, Maxime. Le mer. 6 nov. 2019 à 18:23, R.Wieser a écrit : > Hello all, > > I was doing a "lets print some time-related data", and also diaplayed the > result of "psutil.boot_time()". > > Somewhere while doing that I saw that my clock was off, so I used the > "date" > command to rectify it. > > The thing is, after that the result of "psutil.boot_time()" was changed - > and that I did (and do) not expect. :-( > (Remark: the difference was exactly the same as the change I made with the > "date" command). > > Question: Is there a way to retrieve the "last boot" time /without/ it > getting changed by ... whatever ? > > Regards, > Rudy Wieser > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
psutil.boot_time() ... doesn't ?
Hello all, I was doing a "lets print some time-related data", and also diaplayed the result of "psutil.boot_time()". Somewhere while doing that I saw that my clock was off, so I used the "date" command to rectify it. The thing is, after that the result of "psutil.boot_time()" was changed - and that I did (and do) not expect. :-( (Remark: the difference was exactly the same as the change I made with the "date" command). Question: Is there a way to retrieve the "last boot" time /without/ it getting changed by ... whatever ? Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
