22

I have a mid 2011 27" iMac running Mavericks (10.9.1). I updated from Mountain Lion this Fall when Mavericks was released. I never had any problem before with my system clock.

Since installing Mavericks my clock consistently gains about 20 seconds per day. I have my Time Zone correctly set and "Set Date and Time Automatically" is checked in my Date & Time system preferences. It is set to use "Apple/Americas/U.S. (time.apple.com)"

When I open the Date & Time System Preferences pane my clock gets adjusted immediately to the correct time, but without opening the pane, it gets off track pretty quickly.

I have rebooted, checked and unchecked the box to set the date and time automatically and neither seems to have helped.

Any solutions or ideas?


UPDATE:

I have made what feels like progress. Question: How can I tell if my mac is keeping the clock updated properly? and its accepted answer by grgarside provided a lot of helpful troubleshooting help. My drift is a whopping 499.988 (gains 43.19 seconds per day)!

Most importantly, pacemaker is running every 5 - 15 seconds, as evidenced by my stem log, however, every time it runs it gets an error:

Feb  1 11:53:29 jsw.local pacemaker[19928]: adjtime: Operation not permitted
Feb  1 11:53:39 jsw.local pacemaker[19928]: adjtime: Operation not permitted
Feb  1 11:53:51 jsw.local pacemaker[19928]: adjtime: Operation not permitted
Feb  1 11:53:59 jsw.local pacemaker[19928]: adjtime: Operation not permitted
Feb  1 11:54:09 jsw.local pacemaker[19928]: adjtime: Operation not permitted
Feb  1 11:54:19 jsw.local pacemaker[19928]: adjtime: Operation not permitted

It seems I have a permission problem, but I cannot figure it out. I have unloaded and reloaded the pacemaker plsit via launchctl

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.pacemaker.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.pacemaker.plist

here is a text export of my com.apple.pacemaker.plist

{
    Label = "com.apple.pacemaker";
    ProgramArguments = (
        "/usr/libexec/pacemaker",
        "-b",
        "-e",
        "0.0001",
        "-a",
        10,
    );
    KeepAlive = {
        PathState = {
            "/private/var/db/ntp.drift" = YES;
        };
    };
}

my /private/var/db/ntp.drift file is owned by root:wheel and its permissions are 644, /System/Library/LaunchDaemons/com.apple.pacemaker.plist has exactly the same ownership and permissions.

I hope this update provides enough additional information so that someone can get me past this issue.

  • 2
    I've not ever had the system go off like you describe, but another person here needed to select a different time server (asia if you use US currently) and then switch back to get the setting to stick. – bmike Dec 31 '13 at 23:46
  • I would guess that there is something wrong with your DNS or hostfile. Have you modified your network settings and preferences in any way? Not just under 10.9 but 10.8? I would try changing from time.apple.com to one of pool.ntp.org/en 's URLs. – Andrew U. Jan 3 '14 at 8:27
  • 1
    @AndrewU. Your comment fails to account for the fact that time apparently syncs properly when I open the pref pane – Scott Jan 3 '14 at 19:08
  • 1
    @bmike I am trying this, just haven't been back to that iMac to check things out. Thanks, Scott – Scott Jan 3 '14 at 19:09
  • 1
    I am having the exact same problem - clock drifts by minutes a week, but immediately syncs properly when I open the clock preferences panel. I noticed the "adjtime: Operation not permitted" error can be eliminated it you run pacemaker on the command line via sudo: sudo /usr/libexec/pacemaker -v But that's not really a solution, just maybe a hint at what might be going wrong behind the scenes. – Brian Stormont Apr 17 '14 at 19:31
22

these seem to work ok on my iMac, running Mountain Lion:

0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org time.apple.com

simply copy/paste the space-separated line above into the ’Set date and time automatically’ field, in Date & Time preferences. remember to press Enter after typing the ntp server names, so that ntp.conf gets updated.

  • I don't understand why this worked, but it worked! – Scott Feb 2 '14 at 1:25
  • In Yosemite this has become a drop down which doesn't seem to like being edited (even though it kinda sorta looks like you can edit it...) :( – RedYeti Jul 23 '15 at 17:30
  • You can still edit in Yosemite (I just did!). If you select the dropdown and hit the Delete key, you'll see the text disappear. You cannot use cmd+v to paste, but secondary click give you a paste option in the menu. – Ryan Dlugosz Aug 23 '15 at 18:22
3

Maverisks' ntpd is broken, smashed, corrupt. Apple knows about this: I've spent hours on the phone to them, providing them samples and files galore. It may be a carry over from iOS ("Back to the Mac" whether or not it actually works). The culprit seems to be a new with Maverisks daemon called "pacemaker", which in classic Apple fashion is under documented and does not appear to behave in accordance with what little documentation there is.

  • There is a lenghty discussion about this here: discussions.apple.com/thread/5604114 – shrx Aug 23 '14 at 12:19
  • Check out Bryan Christianson's ChronyControl (Bryan also is behind WhatRoute). It brings some sanity back to ntp timekeeping using Mojave v10.14.4. – outer May 3 at 22:59
2

Before making a fresh install, I strongly suggest you to try resetting your NVRAM(non-volatile RAM).

A NVRAM(or PRAM on older, PowerPC-based Macs) stores certain settings. It's a kind of memory like the regular RAM in your Mac but with one major difference being that a NVRAM stores what's on it even if your Mac gets turned off.

Specifically, information stored in NVRAM / PRAM includes:

  • Speaker volume
  • Time-zone settings
  • Screen resolution
  • Startup disk selection
  • Recent kernel panic, if any

Probably, what's stored on your NVRAM about your time got corrupted somehow and now causes your issue.

Now, you might ask, what about the syncing of time with servers? What do I need that for? Well, it's just for setting your time instead of you doing it manually. Just a little gesture; nothing more. After it gets set then it's stored on your NVRAM as usual.

And your time gets corrected every time you open your Date & Time Preferences because probably opening there initiates a manual syncing of your time with the server. But after that things go haywire again.

Anyway, in order to reset your NVRAM:

  • Shut down your Mac.
  • Locate the following keys on the keyboard: Command (⌘), Option, P, and R. You will need to hold these keys down simultaneously in step 4.
  • Turn on the computer.
  • Press and hold the Command-Option-P-R keys before the gray screen appears.
  • Hold the keys down until the computer restarts and you hear the startup sound for the second time.
  • Release the keys.

Source: Apple

  • 1
    I could see resetting NVRAM clear an incorrect time zone, but as far as it affecting the timekeeping and ability of ntpd to keep the clock from diverging from internet sources - there's a lot of missing links between what's stored in NVRAM and how time gets set. Especially since the system goes out and self-corrects while running by opening the system preference pane. Are you thinking it's getting messed up at boot time perhaps? – bmike Jan 2 '14 at 21:35
2

You can ntpdate via launchd.

I’ve put the pieces together at https://github.com/tjluoma/ntp-fix-time but I’ll include the relevant bits here:

  1. A launchd plist that goes into /Library/LaunchDaemons/ (because it needs to be run as root when it runs)

  2. A shell script that calls ntpdate -u $NTPHOST and logs its output.

For some reason, trying to call ntpdate directly via launchd didn’t work for me, but calling it via a script seemed to work.

The plist uses this:

    <key>RunAtLoad</key>
    <true/>

to make sure it runs when the Mac is rebooted.

This:

    <key>StartInterval</key>
    <integer>14400</integer>

makes sure that it runs every 4 hours, which seemed like it was “often enough.”

The script will use the servers listed in /etc/ntp.conf unless there aren’t any, in which case it will use time.apple.com.

(The man page for ntpdate suggests that it will eventually be ‘retired’ from Mac OS X but it’s still there in 10.9.1, so that’s enough for me.)

  • This looks like it will work - although I am puzzled why it is necessary and if there are other system problems that I am not aware of. – Scott Jan 9 '14 at 9:55
  • 1
    FYI - I'm not a fan of relying on the PATH variable in either LaunchDaemons or cron jobs. I've been burned way too many times, I think it is a much better practice to use the complete path. In the case of LaunchDaemons you can specify a WorkingDirectory which, if used, removes the need to specify the complete path. – Scott Jan 9 '14 at 10:02
1

I have thus far been unsuccessful in eliminating the clock drift. Because my clock drifts slowly (less than a minute per day) It takes a while to see if the attempted solution works.

I have just now tried a variation of Patrix's answer from this post. The echo did not work on the command line, I got "permission denied" (His answer was referencing a Lion install). But I did remove the old file and replace it with a new one which I edited with nano.

sudo rm /etc/ntp.conf
sudo touch /etc/ntp.conf
sudo nano /etc/ntp.conf

in the file I simply placed

server time.apple.com

no trailing . or new line. I then exited nano (ctrl-X) and answered yes to saving changes.

I did not need to change owners since it was already owned by root:wheel.

I'll update when I know if this worked.

  • 1
    This did not work – Scott Jan 5 '14 at 17:08
  • 2
    Why do you touch it before you alter it? – Max Ried Sep 18 '14 at 19:55
0

I wanted to provide my two cents on this problem. I had a similar problem. My clock would be an hour behind and what worked for me was to uncheck the Set time zone automatically using current location, and just manually choosing the closest city. It doesn't hurt to give it a try and see if it makes a difference.

0

As has been discussed elsewhere the clock drift is due to ntpd not working and something called /usr/libexec/pacemaker not working right, either. Disabling pacemaker and running ntpdate to slew the clock has gotten the clock reasonably stable on my system, with minimal system changes.

From Terminal, run these commands in order.

cd /System/Library/LaunchDaemons/
mv com.apple.pacemaker.plist com.apple.pacemaker.plist.OFF
sudo crontab -l > /tmp/foo
echo '*/5 * * * * /usr/sbin/ntpdate -s -B -u time.apple.com' >> /tmp/foo
sudo crontab /tmp/foo

Then restart the system.

The first two commands disable pacemaker by moving its launchd configuration file out of the way. The last three commands tell the system cron daemon to run ntpdate every five minutes, slowing down or speeding up the clock as needed, and logging what it does to /var/log/system.log.

-2

If you call Apple, they will suggest that you do a reinstall preserving the operating system.

My guess is that you have a corrupted preference. You can try changing every setting in the Date and Time preference panel to something else, reboot, then set it to what you want. If that doesn't work go into the Preferences directory and remove anything preference plist that has something to do with Preferences Date and Time.

  • Reinstall? HORRORS! That is why I left Windows years ago. Certainly reasonable, intelligent people can find a better solution than reinstalling an OS. – Scott Jan 5 '14 at 13:49
  • And as far as Going to the Preferences directoty and remove plists having to do with Date and Time. I find that recommendation incomplete and dangerous. If that is seriously your advice you should A) provide the location of the folder. And B) advise the user to move the files elsewhere (desktop perhaps) instead of deleting them. Many people, of various experience levels, will read this question. – Scott Jan 5 '14 at 13:52
  • I gather that you haven't called Apple tech support lately. Reinstalling OSX is a pretty painless operation. All of your apps remain installed, all of your users remain present. – vy32 Jan 5 '14 at 16:58
  • Called Apple yesterday. 3 hours on the phone. Then a 4 hour re-install of the OS (over fast internet onto an SSD). Then 2 hours tweaking config files (apache, etc) that were clobbered by the OS re-install. And after all that - MY CLOCK STILL DRIFTS. Not even close to painless and the problem is not fixed. – Scott Jan 7 '14 at 13:54

You must log in to answer this question.

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