Snow Leopard users: Turn off automatic date and time in System Preferences immediately

Thanks. Nope, I'm not using "Little Snitch". I don't believe there's a entry for ntpd in the Firewall by default, but it appears there after you allow or deny the request. I deleted the entry from my Firewall and I'll see if the request appears again and if it does I'll get a screenshot.

Thank you for the patch! I'm not poking around in log reports, but I checked the version and it is updated, and I'm not seeing any odd messages. Much appreciated!

I would add that although I have a firewall (Intego's), I have not gotten any requests to override it, so I assume that the firewall permits NTP access.

I read the reply to xyzzy-xyzzy's bug report at http://bugs.ntp.org/show_bug.cgi?id=2712 and was able to eliminate the mlock() log entries by editing the /etc/ntp.conf as suggested:

server time.apple.com

rlimit memlock 0

I also eliminated the KOD log entries by replacing 'kod' with 'kod limited' in /etc/ntp-restrict.conf :

restrict default kod limited nomodify notrap nopeer noquery

restrict -6 default kod limited nomodify notrap nopeer noquery

restrict 127.0.0.1

restrict -6 ::1

includefile /private/etc/ntp.conf

Note: It's an easy change in to the configuration files, but I added these files to the installer to make it easier. it can just be rerun to make the latest changes.

I've now developed a set of changes to get rid of some of those system.log messages that have been bugging me. These are the result of my research (i.e., lots of googling) and suggestions in the reply to my ntpd bug report (bug 2712).

1. /usr/libexec/ntpd-wrapper

Change:

for server in $(awk '/^server/ {print $2}' /etc/ntp.conf); do

if sntp -v -r -P no -l /var/run/sntp.pid ${server} &> ${LOG}; then

to:

for server in $(awk '/^server/ {print $NF}' /etc/ntp.conf); do

if sntp -K /dev/null -s ${server} &> ${LOG}; then

This was discussed earlier to use the proper call to sntp to remove the -v error report in the system.log and to make the call actually work.

2. /private/etc/ntp-restrict.conf

Change:

restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

to:

restrict default kod limited nomodify notrap nopeer noquery

restrict -6 default kod limited nomodify notrap nopeer noquery

Adding "limited" to the restrict command gets rid of the "restrict default: KOD does nothing without LIMITED" system.log messages.

Add the following line to ntp-restrict.conf (anywhere -- I stuck it at the end):

# Supppres mlockall() use (and resulting system.log messages) since it is not

# implemented in OSX

rlimit memlock 0

Adding rlimit memlock 0 causes ntpd to not try to lock pages. This will cause ntpd to not try to use mlockall() and thus not report "mlockall(): Function not implemented" messages to the system.log.

Alternatively, instead of adding the rlimit line you could edit confg.h in the ntp sources (after the configure is done of course). Either remove the #define HAVE_MLOCKALL or add a #undef HAVE_MLOCKALL after it. With HAVE_MLOCKALL undefined, the ntpd/ntpd.c code using mlockall() is not included and thus again this will avoid the system.log messages.

With these changes, here's what I now see in my system.log when I toggle ntpd off and on via the Date&Time system preferences (I was using ntpd 4.2.8p1-beta2 here, yes, yet another beta):

Dec 29 13:17:10 xxxx ntpd[13300]: ntpd 4.2.8p1-beta2@1.3265-o Mon Dec 29 20:06:09 UTC 2014 (5): Starting
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: ntpd 4.2.8p1-beta2@1.3265-o Mon Dec 29 20:06:09 UTC 2014 (5): Starting
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Command line: /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
Dec 29 13:17:10 xxxx ntpd[13300]: proto: fuzz beneath 0.077 usec
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto: precision = 1.000 usec (-20)
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto: fuzz beneath 0.077 usec
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen and drop on 0 v6wildcard [::]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 2 lo0 [::1]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 3 lo0 [fe80::1%1]:123
Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 4 lo0 127.0.0.1:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 5 en0 192.168.1.68:123
Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 6 en0 [fe80::ea06:88ff:fecd:4ae9%4]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listening on routing socket on fd #27 for interface updates

I am still seeing two ntpd processes and I am sure now that the ntpd command in ntpd-wrapper is forking to produce a child ntpd process. The child only "lives" for a few minutes leaving just the parent. What's still bothering me about that is the ntpd call uses a -n argument which means "don't fork". So I submitted another Bugzilla report on that (bug 2718). We'll see what comes of that.

--

I've gotten a lot deeper into this ntp stuff than I ever wanted to. 😠

I had the request re-appear and I got screenshots this time:

and clicking the "?" brings up the following:

I once again clicked "Deny". As far as I can remember I never saw this request before applying the NTP patch.

flatsixracer wrote:

I read the reply to xyzzy-xyzzy's bug report at http://bugs.ntp.org/show_bug.cgi?id=2712 and was able to eliminate the mlock() log entries by editing the /etc/ntp.conf as suggested:

server time.apple.com

rlimit memlock 0

I also eliminated the KOD log entries by replacing 'kod' with 'kod limited' in /etc/ntp-restrict.conf :

restrict default kod limited nomodify notrap nopeer noquery

restrict -6 default kod limited nomodify notrap nopeer noquery

restrict 127.0.0.1

restrict -6 ::1

includefile /private/etc/ntp.conf

Note: It's an easy change in to the configuration files, but I added these files to the installer to make it easier. it can just be rerun to make the latest changes.

For a moment I was confused how you could reply to the post I was in the process of constructing (the one that followed yours). At least I was confused until I read it again and saw you were monitoring the bug report and posted while I was constructing my post. 😉

At any rate my summary of suggested changes followed your post. Notice I placed the rlimit in ntp-restrict.conf and not ntp.conf. The reason I did this is (a) all the ntpd conf changes are localized to the single ntp-restrict.conf file and (b) I thought I better stay clear of ntp.conf. The reason for the latter is ntp.conf is where the ntp server is specified and I assume that file is edited/changed/replaced if a user changes the time server in the Date&Time system preferences. Admittedly I didn't verify that because I figured it wasn't worth the effort. But if it is changed you might risk loosing the rlimit command if you put it in ntp.conf.

As for bug 2718 I reported about seeing two ntpd processes. Here's what they said:

You're seeing the 2nd ntpd process because that's where the DNS resolution of

time.apple.com is being done. That mechanism is independent of the -n switch.

So I asked whether it's always been that way since I never saw if before I started using 4.2.8. The response was "yes". This lead to the speculation that Apple may be doing their own changes to the ntp sources. That may be why the latest ntp security update from Apple yields a ntpd that still says version 4.2.6 and not 4.2.8. Just speculating here.

I did toss in a remark questioning the "setsockopt IPV6_MULTICAST_IF..." in the logs. They couldn't say anything useful on those. So I guess those log entries stay. I did check that you probably could get rid of them by adding --enable-ipv6=no to the configure step. But I am not even going to try.

So that's it then. I guess that's as far as we (or at least I) go. I guess time will tell (pun intended, couldn't resist) if everything works!

flatsixracer, could you add version numbers to your ntp 4.2.8.pkg, such as ntp 4.2.8 version 3.pkg? I'm already confused, and can't confidently match the date of the file on your Google Drive to the date of your posts saying that it's been updated. (We now are on the third version... right?)

This prepackaged installer looks like a much simpler solution.

https://github.com/MacMiniVault/NTPUpdateSnowLeopard

flatsixracer's revised installer is at the original URL:

https://drive.google.com/folderview?id=0BxQCbeIgpA2uVjFiN1h4bGZNQ2c&usp=sharing

It now requires a restart. I've not looked for error messages, but I did try mis-setting the clock and then re-enabling auto time, and it corrected correctly.

Any chance of making an installer for 10.5 PPC since

http://www.macissues.com/2014/12/24/how-to-manually-patch-ntp-for-os-x-10-6-and- 10-7/

works for 10.5 (I can send the files if you need)