The following code calculates the epoch time of boot.
console.log(Math.floor(new Date() /1000) - os.uptime())
It should be constant, but there is a 1-second anomaly.
Anyone knows why?
The OS doesn't necessarily start exactly on the second boundary. While you're getting OS uptime down to the second, it may have came up part of the way through a second.
Related
I am trying to monitor the uptime and send data at high frequency on node.js server. The server will broadcast network data every few milliseconds.
But using Date.now() is not accurate enough. So I am thinking of using the high resolution timer process.hrtime(). I don't know what is the max value of process.hrtime. I need to run the server for at least 6 months. Will it overflow very soon?
Primary use of process.hrtime() is is for measuring performance between intervals (docs) but it can be also used for measuring uptime with nanosecond precision.
It returns time in array [seconds, nanoseconds], where nanoseconds are the remaining part of time not representable by whole second.
Seconds will reach max safe integer (9007199254740991) in thousands of years. Nanosecond will never reach it as the maximum nanoseconds not representable by whole second is 999999999.
In a Linux CentOS 5 machine, I am running process.sh using a cronjob at #reboot, every day (the machine gets shut off every night and turned on every morning).
process.sh takes the 'date' of the computer, and writes it to a log file, then exits.
When I check the logfile, the timestamp in it says "Tue Jan 1 13:14:38 GMT 2008"
When I go to the console of the computer and give it the 'date' command, it prints the correct date.
My best guess is that my cronjob is running BEFORE the computer sets its correct time.
Is there a way to fix this?
The battery that powers the CMOS memory on your motherboard may have run out. Try replacing it by a fresh one. It should look something like this.
This advice is based on the fact that the date of your log entry is "Jan 1 2008" which looks conspicuously like an epoch your motherboard may use. However, the time-of-day 13:14:38 is a little off for this; while the 13 hour shift can be explained if you are in the correct time zone, the nearly 15 minute offset seems odd. Unless your computer takes that long to boot to the point where cron executes your job. And of course, the reason why you eventually see the correct time is probably that ntp fixed the system time, as others have noted.
I current run into an issue that a process seems stuck somehow, it just doesn't gets scheduled, the status is always 'S'. I have monitored sched_switch_task trace by debugfs for a while, didn't see the process get scheduled. So I would like to know when is that last time scheduled of this process by kernel?
Thanks a lot.
It might be possible using the info in /proc/pid#/sched file.
In there you can find these parameters (depending on the OS version, mine is opensuse 3.16.7-21-desktop):
se.exec_start : 593336938.868448
...
se.statistics.wait_start : 0.000000
se.statistics.sleep_start : 593336938.868448
se.statistics.block_start : 0.000000
The values represent timestamps relative to the system boot time, but in a unit which may depend on your system (in my example the unit is 0.5 msec, for a total value of ~6 days 20 hours and change).
In the last 3 parameters listed above at most one appears to be non-zero at any time and it I suspect that the respective non-zero value represents the time when it last entered the corresponding state (with the process actively running when all are zero).
So if your process is indeed stuck the non-zero value would have recorded when it got stuck.
Note: this is mostly based on observations and assumptions - I didn't find these parameters documented anywhere, so take them with a grain of salt.
Plenty of other scheduling info in that file, but mostly stats and without documentation difficult to use.
Was reading "Understanding Linux Kernel" book and in it says that, "number of microseconds is calculated by do_fast_gettimeoffset( )". Also it says that "to count the number of microseconds that have elapsed within the current second."
Couldnt understand what the author means by last sentence. Could anyone explain more on that?
If you want to understand the linux kernel, you should be aware that that book has been outdated for a long time and that do_fast_gettimeoffset no longer exists.
do_get_fast_time returns the number of seconds, and is always fast.
do_gettimeoffset returns the number of microseconds since the start of the second, and might be slow.
I'm working on a machine which has some code running on it which sets the time when I set the password. The time set is epoch time, but it has 13 digits in it, and when I wrote a simple program to get the epoch time and ran it on my personal computer running linux, it returns the epoch time which has 10 digits. Would anyone know what the extra three digits signify?
Thanks in advance
Probably seconds vs milliseconds.
You'd have to consult the specific documentation though.