Timeline for How to force a clock update using ntp?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| 2 days ago | comment | added | Niklas Rosencrantz | Unit ntp.service not found. I don't understand. All I wanted was to set the time on the computer. | |
| Sep 27, 2021 at 16:32 | comment | added | alper |
It gives following error: Failed to start ntp.service: Unit ntp.service is masked.
|
|
| Aug 18, 2019 at 11:46 | comment | added | subtleseeker |
ntp is deprecated in newer versions. Instead use systemd-timesyncd.service.
|
|
| Feb 22, 2018 at 10:56 | comment | added | jaygooby |
I had the same problem and worked through all the different solutions - none worked for me; TLDR was that I was on an EC2 instance and needed to let Xen know I wanted to run my own clock: sudo bash -c 'echo 1 > /proc/sys/xen/independent_wallclock' and sudo bash -c 'echo xen.independent_wallclock=1 >> /etc/sysctl.conf' - then both ntpdate and ntpd -gq options worked
|
|
| Jun 23, 2017 at 22:40 | comment | added | Mark Lakata |
On my system, the full paths to the scripts in init.d end in d, e.g. /etc/init.d/ntpd start etc.
|
|
| Mar 3, 2017 at 14:09 | comment | added | Edward Anderson |
With the -u option, you don't need to stop the ntp service: sudo ntpdate -u time.nist.gov
|
|
| Feb 28, 2017 at 2:24 | comment | added | datakid | As noted below, ntp is deprecated | |
| Oct 14, 2016 at 6:05 | comment | added | ysap | @pguardiario - this is definitely a very constructive and educating comment... | |
| Aug 7, 2014 at 22:48 | review | Suggested edits | |||
| Aug 7, 2014 at 22:57 | |||||
| Feb 16, 2013 at 1:25 | comment | added | ysap |
I did found out that the us.pool.ntp.org is more responsive.
|
|
| Feb 16, 2013 at 1:23 | vote | accept | ysap | ||
| Feb 16, 2013 at 1:23 | comment | added | ysap | OK, this was apparently the problem. Now the clock is being updated as soon as the network connection is established. Thanks. | |
| Feb 16, 2013 at 0:19 | comment | added | ysap | mmm... that definitely makes sense. I will try. | |
| Feb 15, 2013 at 23:40 | history | edited | Eric Carvalho | CC BY-SA 3.0 |
deleted 9 characters in body
|
| Feb 15, 2013 at 23:34 | history | edited | Eric Carvalho | CC BY-SA 3.0 |
deleted 9 characters in body
|
| Feb 15, 2013 at 23:18 | comment | added | Eric Carvalho | I guess the network is still down when rc.local runs. I added a loop to test Internet reachability and if so proceed with ntpdate. Check my answer. | |
| Feb 15, 2013 at 23:15 | history | edited | Eric Carvalho | CC BY-SA 3.0 |
added 72 characters in body
|
| Feb 15, 2013 at 21:42 | comment | added | ysap | Eric, please see update #2 to the question. | |
| Feb 14, 2013 at 22:54 | comment | added | ysap |
I tried changing rc.local accordingly, but then the clock won't update at all, even not from command line.
|
|
| Feb 14, 2013 at 21:43 | comment | added | Eric Carvalho |
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.
|
|
| Feb 14, 2013 at 21:06 | comment | added | ysap | Thanks. Can you please explain why you need the explicit paths? | |
| Feb 14, 2013 at 19:09 | history | edited | Eric Carvalho | CC BY-SA 3.0 |
added 182 characters in body
|
| Feb 13, 2013 at 23:13 | history | answered | Eric Carvalho | CC BY-SA 3.0 |