Introduction
Recently in an application I developed, I noticed I received a unauthorized response for an API GET to a RESTful Service which I developed in Symfony. I was baffled as to why I would all of a sudden get an unauthorized response, since the app was previously working. In this case, my app sends X-WSSE headers to authenticate using the WSSE protocol, which I described previously in my REST Easy With Symfony article.
What I found is that there was drift occurring in the virtual machine guest, and it was losing up to 6 minutes in a month, which was a large amount of time drift.
Adjusting the Time
I found the simplest solution to adjust the time in the guest was to run the following command:
ntpdate time.nist.gov
The above command just runs the “ntpdate” command with the parameter “time.nist.gov”, which essentially polls an ntp server to synchronize time on the guest. One way to use this command to compensate for the time drift, is to occasionally run the command; however, this is not feasible, since I may not check the machine(s) very often.
Cron to the Rescue
Cron is a system scheduler that allows you to run a command or script at very specific time(s). Most Linux operating systems have the command “crontab” which makes it easy to edit and list the cron scheduler. To edit your own (that belongs to the user role you are logged in as) cron scheduler, run the following command:
crontab -e
The “-e” parameter specifies “edit” and opens the default crontab editor (which is normally vi). You can then use the standard vi editor command to edit the cron file as to your required needs. If you need to see how the cron scheduler is configured, then run the following command:
crontab -l
The “-l” parameter specifies “list”, so it lists the cron scheduler settings.
Format of the Cron File
The cron file that gets created normally resides in “/var/spool/cron”, so you could run:
sudo /var/spool/cron
Which would list all the cron files for all the users on the system. The above presumes you have been added to the “sudo” users list, otherwise you would not be able to run the command.
The following diagram shows the format of the cron file:
Each item is separated by a space, so the above file runs the “ntpdate” command at “0” minutes” and “0” hours (midnight), everyday of the month, every month, and every day of the week.
Running as the Root User
In my case, I normally log onto this system as a “user” and not the “root” user. The “ntpdate” also needs to be run as the root user. So I have to run it from the command line like so:
sudo ntpdate time.nist.gov
So the question then is, how do you do this in cron? If you put the above in your own cron scheduler using “crontab -e”, it will fail when it tries to run, since you are not the root user.
The solution is to run “crontab” with sudo. So you would use this command:
sudo crontab -e
This creates a cron file for the “root” user.
Running More Frequently
I noticed when I ran the above cron scheduler (root cron job) only at midnight, the clock didn’t synchronize fully. So I wanted to increase the number of times it runs. To do that, run “sudo crontab -e” and let’s make it run 3 times a day:
0 0,08,16 * * * sudo ntpdate time.nist.gov
The above changes will now run everyday at midnight, 8:00 AM, and 4:00 PM.
Verifying Cron Job Ran
To check that the above cron job actually ran successfully, you can check the cron log file which is normally located in the folder “/var/log” and will have the file name “cron”. If your system uses log rotate, then older logs will have a timestamp appended; for example “cron-20170522”.
To verify, just open the cron log file and search for “ntpdate”, and you should see that the command is run by the root user.
Hopefully, this helps someone that needs to run a scheduled command or script.
