11

In the recent weeks I've noticed each morning that my clock would be behind by 2-3 minutes. I've noticed that opening the 'Date & Time' dialog from System Preferences will trigger the clock to resynchronize to Apple's time servers. I am running OS X 10.7.4 Lion on an 8,2 MacBook Pro.

What might be causing this lack of automatic resynchronization?

EDIT: I compared my /etc/ntp.conf file to a peer's also running Lion, and we noticed that my file contained:

0000000: 7365 7276 6572 2074 696d 652e 6170 706c  server time.appl
0000010: 652e 636f 6d2e 0a                        e.com..

while his had:

0000000: 7365 7276 6572 2074 696d 652e 6170 706c  server time.appl
0000010: 652e 636f 6d                             e.com

His last modification date on the was mid-2010, while mine was last modified only a week or two ago (around when the issue started?). I certainly did not manually edit the file. Possibly related?

EDIT 2: I noticed that, if I change my time server in 'Date & Time' to, say, Asia, my /etc/ntp.conf file becomes:

0000000: 7365 7276 6572 2074 696d 652e 6173 6961  server time.asia
0000010: 2e61 7070 6c65 2e63 6f6d 2e0a            .apple.com..

complete with trailing 0x2e character. So, it seems that OS X adds the trailing . automatically, but a fresh Lion system does not contain this trailing character. Still unsure whether this is affecting the synchronization though.

EDIT 3: It's been 24 hours since I changed the time server to 'Apple Asia' and then back to 'Apple Americas' -- no time drift. Bizarre.

Improve this question
1
  • Just a general comment... I would have thought the computer clock should keep better time, without having to constantly resync with a time server? My desktop PC is set to resync once a week, but does not loose any noticeable time in that period. Years ago when I used to service PCs, a slow system clock was often the result of a failing lithium button battery?!
    – MrWhite
    Jun 13, 2012 at 16:06

2 Answers 2

Reset to default
6

Looks like some special characters got inserted at the end (especially the 0x2e part which represents a simple .) and OS X now interpretes this as part of the server name. To fix, just run

sudo echo server time.apple.com > /etc/ntp.conf
sudo chown root:wheel /etc/ntp.conf

from the Terminal.

As to why you have this issue I have no clue.

Improve this answer
4
  • I suspected as much. I've already edited the file to not contain the 0x2e character and rebooted, and am basically waiting to see whether I accumulate significant drift again. Still, I would love to know how this could have happened and why opening 'Date & Time' causes it to apparently not use the ntp.conf file to resync?
    – noffle
    Jun 13, 2012 at 15:04
  • 1
    Changing the server from within "Date & Time" would probably have solved the issue as well. Opening the pane without any changes doesn't trigger a configuration file update.
    – nohillside ♦
    Jun 13, 2012 at 15:07
  • When changing the time server via the "Date & Time" dialog, OS X actually changes the ntp.conf file to contain the 0x2e character and trailing newline. I don't think this is the cause.
    – noffle
    Jun 14, 2012 at 17:26
  • Ah, when I change the server name via "Date & Time" I get the trailing . as well. Seems to be a Lion issue then.
    – nohillside ♦
    Jun 14, 2012 at 20:38
2

Since I (experimentally) made the following change, I've ceased to have clock drift issues, despite by /etc/ntp.conf file's contents not technically changing:

Open the Date & Time settings dialog, change the time server from Apple Americas/U.S. (time.apple.com) to Apple Asia (time.asia.apple.com) and then back to Apple Americas/U.S. (time.apple.com). From there, my daily time drift has ceased to occur.

This is a rather unsatisfying answer -- I'd love to change the select answer if anyone comes up with the real, underlying cause.

Improve this answer
1
  • Although not a definitive answer, I have experienced .plist files becoming corrupted and causing all sorts of problems that are seemingly fixed by making a 'radical' preference change, and then going back to 'normal.' This forces the .plist file to be written afresh, overwriting the corrupt bits.
    – IconDaemon
    Jan 1, 2014 at 2:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .