Timeline for NTPDate runs three times at boot resulting in incorrect date
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 28, 2014 at 17:31 | comment | added | mc0e | Like @Gilles said, multiple ntpdate requests should be harmless. Ntpdate should be creating a lock file which prevents concurrent runs. If you are seeing problems from multiple ntpdate runs due to your different indexes coming up in quick succession, then maybe there's some sort of race condition, which is a bug which should be reported. I'm sceptical though about whether the problem is as you describe it. | |
| Aug 16, 2012 at 21:08 | vote | accept | DanielGibbs | ||
| Nov 18, 2011 at 1:20 | comment | added | DanielGibbs | When ntpdate fails to run at all (usually if I've broken a script somewhere) the system defaults to January 1944, so the offset sounds about right. I'm not sure what else I need to fix, but it works fine now. | |
| Nov 18, 2011 at 1:14 | comment | added | Gilles 'SO- stop being evil' |
There's probably something else that you need to fix. Making several ntpdate requests should be harmless. The insanely large offset you see (67-odd years, about 71.5 days short of 2³¹ seconds) is not normal.
|
|
| Nov 17, 2011 at 23:15 | history | answered | DanielGibbs | CC BY-SA 3.0 |