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.
Related
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.
i still want to check my Bootloader + Linux Startupcode for an embedded device. Therefore i want to catch the time for every command printed to the serial port.
I know there are programs like putty (which i can dearly recommend), getty, cutecom, picocom, screen etc. But none of these add timestamps to the incomming messages on the host screen (I'm not really talking about the date, more like how many ms have gone since the first output). It actually sounds not like a big deal.
I found out there is one script doing what i wanted to have, called grabserial but it's not working properly, since it's to slow to process the whole output. I discussed this problem in a different forum (if you want to know: grabserial problem but it's not part of the topic). So i can't use that script.
Now again: can you tell me a terminal for Linux which adds timestamps to every line, which was received from a Serial Port?
Thank you
[Edit:] I've found a pretty rough workaround with cereal, which wants to have some settings, since it locks the port everytime you use it. In the end, it adds the actual date and time, not the startup time and difftime between each step, so as you can see I'm still looking for an adequate solution.
This might come 3 years too late, but minicom (https://en.wikipedia.org/wiki/Minicom) supports timestamps for every line printed on the terminal. In Ubuntu it's directly available in the default repos.
You might want to look in to using strace to monitor the serial port. See How can I monitor data on a serial port in Linux?
If you are willing to build the binary by yourself, you can try a branched picocom (https://github.com/codepox/picocom). This is based on picocom 1.7 which is a little old.
I have forked and enhanced this picocom and made it be able to show either delta-time or wall-clock timestamp. You can find it here (https://github.com/tdwong/picocom-with-timestamp). You still have to build the binary by yourself.
Here is how I use it. Note, N is the command to enable/toggle timestamp.
$ picocom -b 115200 /dev/ttyUSB0
...
<ctrl-a> N # enable delta-time timestamp
<ctrl-a> N # toggle wall-clock timestamp
<ctrl-a> N # disable timestamp
tio found at https://tio.github.io provides various timestamp options:
-t, --timestamp
Enable line timestamp.
--timestamp-format <format>
Set timestamp format to any of the following timestamp formats:
24hour 24-hour format ("hh:mm:ss.sss")
24hour-start 24-hour format relative to start time
24hour-delta 24-hour format relative to previous timestamp
iso8601 ISO8601 format ("YYYY-MM-DDThh:mm:ss.sss")
Default format is 24hour
In your case, showing how much time has passed since start, that would be something like this:
tio -t --timestamp-format 24hour-start /dev/ttyUSB0
Settings can also be enabled in tio configuration file ~/.tioconfig
I believe that ExtraPuTTY is the solution you are looking for.
However, I wasn't clear if you wanted something to run ON Linux or just to be able to monitor it (SSH to Linux). If you didn't want a Windows solution, then I apologize.
I would like to run jobs once a month on, let's say, the 22nd day of the month, on my laptop running Ubuntu 12.04.
Since it's a laptop, and I may not always even use it every 22nd day of each month, cron is not a very good option.
Looking into anacron, there seems to be a limitation. Namely, you can specify a 'period', but not a specific day of the week or day of the month, as suggested by the anacrontab file format:
# cat /etc/anacrontab
period delay job-identifier command
7 15 test.daily /bin/sh /home/myself/backup.sh
I would like to be able to say, if we're on the 22nd day of the month, and of course the laptop is running, run the job. If the 22nd is passed and you have not run the job, run it as soon as I boot.
I am about to do something ugly, like mixing cron and anacron with custom scripts or writing my own bash script, using timestamps, probably reinventing the square wheel in the process.
Any idea about a best course of action?
Cheers.
Run the command daily, and have the script record the date that it last performed a backup
When it starts up, get the current day of month. If it's the 22nd oh the month, run normally and save the date. If it's >22, and the last run was in the same month, exit. If it's <22, and the last run was the previous month (don't forget to account for wrapping from 12 to 1), exit.
The date should be saved in a file somewhere.
It's a remote server so no GUI or fancy stuff installed, I connect to that host using SSH.
For security reasons I suppose, I cannot use the 'date -s' command to change the local server's current time.
$ cat /etc/issues ==> Ubuntu 10.04 LTS
$ uname -r ==> 2.6.32-042stab037.1
$ cat $SHELL ==> /bin/bash
'date' shows me time that is about 10 minutes early, I tried linking the right time from /usr/share/zoneinfo (New york in my case) to /etc/localtime, but nothing really changed, my clock is still 10 minutes unsynchronized.
Do I have to generate a new time zone binary using zic? Yes? how? no? What else could I try ?
Thanks a bunch in advance.
/s
Use adjtimex(8) to set the system clock of a running system. It will smoothly adjust the time and not leave any scary gaps as date would. The syntax for using it is quite beyond me, however, so I just use ntp and forget it.
If your clock issues persists accross reboots you will need to reset the hardware clock with hwclock as well.
Did you think about installing a ntp daemon to keep your time synchronized to avoid those time slicing ?
Ntpd is a good starting point (it is provided in debian packages ntp and openntpd)
You'll have to set a server reference (usually ntp.pool.org, but you can change it if you need) and then, launch it on machine startup.... and let him do the job (ie : keep the time synchronized)
How can I get a history of uptimes for my debian box? After a reboot, I dont see an option for the uptime command to print a history of uptimes. If it matters, I would like to use these uptimes for graphing a page in php to show my webservers uptime lengths between boots.
Update:
Not sure if it is based on a length of time or if last gets reset on reboot but I only get the most recent boot timestamp with the last command. last -x also does not return any further info. Sounds like a script is my best bet.
Update:
Uptimed is the information I am looking for, not sure how to grep that info in code. Managing my own script for a db sounds like the best fit for an application.
Install uptimed. It does exactly what you want.
Edit:
You can apparantly include it in a PHP page as easily as this:
<? system("/usr/local/bin/uprecords -a -B"); ?>
Examples
the last command will give you the reboot times of the system. You could take the difference between each successive reboot and that should give the uptime of the machine.
update
1800 INFORMATION answer is a better solution.
You could create a simple script which runs uptime and dumps it to a file.
uptime >> uptime.log
Then set up a cron job for it.
Try this out:
last | grep reboot
according to last manual page:
The pseudo user reboot logs in each time the system is rebooted.
Thus last reboot will show a log of all reboots since the log file
was created.
so last column of #last reboot command gives you uptime history:
#last reboot
reboot system boot **************** Sat Sep 21 03:31 - 08:27 (1+04:56)
reboot system boot **************** Wed Aug 7 07:08 - 08:27 (46+01:19)
This isn't stored between boots, but The Uptimes Project is a third-party option to track it, with software for a range of platforms.
Another tool available on Debian is uptimed which tracks uptimes between boots.
I would create a cron job to run at the required resolution (say 10 minutes) by entering the following [on one single line - I've just separated it for formatting purposes] in your crontab (cron -l to list, cron -e to edit).
0,10,20,30,40,50 * * * *
/bin/echo $(/bin/date +\%Y-\%m-\%d) $(/usr/bin/uptime)
>>/tmp/uptime.hist 2>&1
This appends the date, time and uptime to the uptime.hist file every ten minutes while the machine is running. You can then examine this file manually to figure out the information or write a script to process it as you see fit.
Whenever the uptime reduces, there's been a reboot since the previous record. When there are large gaps between lines (i.e., more than the expected ten minutes), the machine's been down during that time.
This information is not normally saved. However, you can sign up for an online service that will do this for you. You just install a client that will send your uptime to the server every 5 minutes and the site will present you with a graph of your uptimes:
http://uptimes-project.org/
i dont think this information is saved between reboots.
if shutting down properly you could run a command on shutdown that saves the uptime, that way you could read it back after booting back up.
Or you can use tuptime https://sourceforge.net/projects/tuptime/ for a total uptime time.
You can use tuptime, a simple command for report the total uptime in linux keeping it betwwen reboots.
http://sourceforge.net/projects/tuptime/
Since I haven't found an answer here that would help retroactively, maybe this will help someone.
kern.log (depending on your distribution) should log a timestamp.
It will be something like:
2019-01-28T06:25:25.459477+00:00 someserver kernel: [44114473.614361] somemessage
"44114473.614361" represents seconds since last boot, from that you can calculate the uptime without having to install anything.
Nagios can make even very beautiful diagrams about this.
Use Syslog
For anyone coming here searching for their past uptime.
The solution of #1800_Information is a good advise for the future, but I needed to find information for my past uptimes on a specific date.
Therefore I used syslog to determine when that day the system was started (first log entry of that day) and when the system was shutdown again.
Boot time
To get the system start time grep for the month and day and show only the first lines:
sudo grep "May 28" /var/log/syslog* | head
Shutdown time
To get the system shutdown time grep for the month and day and show only the last few lines:
sudo grep "May 28" /var/log/syslog* | tail