Tell me more ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I am running Ubuntu on an ARM based embedded system that lacks a battery backed RTC. The wake-up time is somewhere during 1970. Thus, I use the NTP service to update the time to the current time.

I added the following line to /etc/rc.local file:

sudo ntpdate -s time.nist.gov

However, after startup, it still takes a couple of minutes until the time is updated, during which period I cannot work effectively with tar and make.

How can I force a clock update at any given time?

UPDATE 1: The following (thanks to Eric and Stephan) works fine from command line, but fails to update the clock when put in /etc/rc.local:

$ date ; sudo service ntp stop ; sudo ntpdate -s time.nist.gov ; sudo service ntp start ; date
Thu Jan  1 00:00:58 UTC 1970
 * Stopping NTP server ntpd     [ OK ] 
 * Starting NTP server          [ OK ] 
Thu Feb 14 18:52:21 UTC 2013

What am I doing wrong?

UPDATE 2: I tried following the few suggestions that came in response to the 1st update, but nothing seems to actually do the job as required. Here's what I tried:

  1. Replace the server to us.pool.ntp.org
  2. Use explicit paths to the programs
  3. Remove the ntp service altogether and leave just sudo ntpdate ... in rc.local
  4. Remove the sudo from the above command in rc.local

Using the above, the machine still starts at 1970. However, when doing this from command line once logged in (via ssh), the clock gets updated as soon as I invoke ntpdate.

Last thing I did was to remove that from rc.local and place a call to ntpdate in my .bashrc file. This does update the clock as expected, and I get the true current time once the command prompt is available.

However, this means that if the machine is turned on and no user is logged in, then the time never gets updates. I can, of course, reinstall the ntp service so at least the clock is updated within a few minutes from startup, but then we're back at square 1.

So, is there a reason why placing the ntpdate command in rc.local does not perform the required task, while doing so in .bashrc works fine?

share|improve this question

4 Answers

up vote 4 down vote accepted

Probably the ntp service is running, that's why ntpdate can't open the socket (port 123 UDP) and connect to ntp server.

Try from command line:

sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start

If you want to put this in /etc/rc.local use the following:

( /etc/init.d/ntp stop
until ping -nq -c3 8.8.8.8; do
   echo "Waiting for network..."
done
ntpdate -s time.nist.gov
/etc/init.d/ntp start )&
share|improve this answer
Thanks. Please see my update to the question. – ysap Feb 14 at 18:58
Thanks. Can you please explain why you need the explicit paths? – ysap Feb 14 at 21:06
I don't really know. :-) I had trouble once trying to run service from rc.local and cron but I managed to fix it using /etc/init.d/xxx instead. Actually I think you don't have to give the full path to ntpdate, I like to use full paths in scripts just to be sure the right file wiill be found. – Eric Carvalho Feb 14 at 21:43
I tried changing rc.local accordingly, but then the clock won't update at all, even not from command line. – ysap Feb 14 at 22:54
Eric, please see update #2 to the question. – ysap Feb 15 at 21:42
show 4 more comments

ntpdate is a program different from the net dameon. NTPDate is probably erroring out on boot because ntpd is running on that socket.

From the command line, run

# sudo service ntp stop ; sudo ntpdate -s time.nist.gov ; sudo service ntp start

You could also uninstall ntpd all together (apt-get remove ntp) and add a cron script to use ntpdate every hour or so.

UPDATE

ntp service probably won't have meaningful value for you on this system, so remove that first.

# sudo apt-get remove ntp

Now add the command:

ntpdate -sb time.nist.gov

to /etc/rclocal

Reboot. Should be good at that point.

share|improve this answer
Thanks. Please see my update to the question. – ysap Feb 14 at 18:58
answer updated. – Stephan Feb 14 at 19:53
Isn't ntpdate being phased out or something? Also, If I understand this correctly, the service runs and maintains the sync of the local clock to the server's clock - so the drift is bound. If you remove ntp and run ntpdate once, won't it be affected by clock drifting when the machine is on for extended periods? – ysap Feb 14 at 21:07
Stephan, please see update #2 to the question. – ysap Feb 15 at 21:42

Try using the -b option to step the time.

share|improve this answer
When trying from command line, I get the following response: 1 Jan 00:04:11 ntpdate[2226]: the NTP socket is in use, exiting . However, I think that I tried this before in rc.local but it did not help. – ysap Feb 13 at 22:28

Instead of ntpdate, use ntpd -gq.

share|improve this answer
Thanks. Still showing 1970 after this command (w/ sudo). Reading ntpd manpage, I am not sure how this forces an update? – ysap Feb 14 at 18:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.