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

flatsixracer wrote:

 

Here is the correct link to the installer.

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

Thank you flatsixracer.

flatsixracer wrote:

 

Here is the correct link to the installer. (I can't update/edit the link on my previous post)

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

I'd like to know if others see the following behavior on their Snow Leopard system using flatsixracer's installer (or your own privately built ntpd from www.ntp.org)...

When you restart ntpd via the Date&Time preferences (toggle the "Set date and time automatically" checkbox), do a ps ax|grep ntpd on the terminal.  How many ntpd processes do you see?  Also what do you see in the system.log (using Console) when you restart ntpd? 

For me I see two ntpd processes and a bunch of system.log messages.  None of this happens with my original 4.2.4p4 ntpd on my 10.6.7 system.  I would like to know if this is specific to my 10.6.7 environment or Snow Leopard in general.

My current theory is that if you do see two ntpd processes I believe it is related to the stuff reported in the system.log and the (parent?) ntpd process spawns the second.  Eventually that second ntpd process times out (I think it's a time out) leaving only the original ntpd process.  I do not know if this is acceptable behavior so at the moment I am a bit wary of using ntp 4.2.8 in my system at the moment.

Have you tried to restart the system/computer?

You are correct, I was able to reproduce the same issue on 10.6.8. But, after the second process times out or goes away it works fine and I don't see any additional entires in the system.log

flatsixracer wrote:

 

Have you tried to restart the system/computer? I think  the old ntpd process is a hanging state, because it's binary was replaced with the new ntpd.

 

Note: I rebooted all my systems after I applied the ntp 4.2.8 fix. On one of my computer I also had two ntpd's running, but that was fixed after the reboot.

 

ps -ef|grep -i ntpd

    0 32782     1   0   0:01.93 ??         0:02.86 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift

Of course I reboot just to be sure all "old" ntp related files are not "floating" around :-)    But did you try the toggle test I described, i.e., toggle the ntpd off and on via Date&Time, watching system.log, and seeing how many ntpd processes are running at that point?

FWIW, here's the portion of the system.log I see when toggling ntpd back on.  I captured this portion at a time when testing my own build of ntp 4.2.8 (and it also happens with 4.2.8p1-beta2) but using your build results in basically the same (not running on that test system at the moment):

Dec 26 14:32:45 xxxx _cvmsroot[700]: /usr/bin/sntp: illegal option -- v

Dec 26 14:32:45 xxxx _cvmsroot[700]: sntp - standard Simple Network Time Protocol client program - Ver. 4.2.8p1-beta1

Dec 26 14:32:45 xxxx _cvmsroot[700]: Usage:  sntp [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \

Dec 26 14:32:45 xxxx _cvmsroot[700]:         [ hostname-or-IP ...]

Dec 26 14:32:45 xxxx _cvmsroot[700]: Try 'sntp --help' for more information.

Dec 26 14:32:45 xxxx ntpd[696]: ntpd 4.2.8p1-beta1@1.3265-o Thu Dec 25 11:28:35 UTC 2014 (1): Starting

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: ntpd 4.2.8p1-beta1@1.3265-o Thu Dec 25 11:28:35 UTC 2014 (1): Starting

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Command line: /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift

Dec 26 14:32:45 xxxx ntpd[696]: proto: fuzz beneath 0.077 usec

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: proto: precision = 1.000 usec (-20)

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: proto: fuzz beneath 0.077 usec

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen and drop on 0 v6wildcard [::]:123

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen and drop on 1 v4wildcard 0.0.0.0:123

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen normally on 2 lo0 [::1]:123

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen normally on 3 lo0 [fe80::1%1]:123

Dec 26 14:32:45 xxxx ntpd[696]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen normally on 4 lo0 127.0.0.1:123

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen normally on 5 en0 [fe80::ea06:88ff:fecd:4ae9%4]:123

Dec 26 14:32:45 xxxx ntpd[696]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listen normally on 6 en0 192.168.1.68:123

Dec 26 14:32:45 xxxx ntpd[696]: restrict default: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: Listening on routing socket on fd #27 for interface updates

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: restrict default: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx ntpd[696]: restrict ::: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: restrict default: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: restrict ::: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: restrict ::: KOD does nothing without LIMITED.

Dec 26 14:32:45 xxxx ntpd[696]: mlockall(): Function not implemented

Dec 26 14:32:45 xxxx org.ntp.ntpd[696]: 26 Dec 14:32:45 ntpd[696]: mlockall(): Function not implemented

Note, the obvious strange things here are the error complaining about -v not being a valid sntp argument.  The -v isn't in a valid sntp argument with the sntp installed with these builds.  But then that then begs the question on whether ntpd-wrapper needs changing since it looks to me that's where sntp -v is used.

The second thing is the error at the end about mlockall() not being implemented.  That has me a little concerned.

Like I said I still don't know if this is specific to my 10.6.7 or a general "problem" with 4.2.8 on Snow Leopard.  Do the toggle test and tell me what you see.  Thanks in advance.

One final point.  It may be true that 4.2.8 might do more logging than 4.2.4p4 so just because 4.2.4p4 is silent in the system.log is not an indications that some things may even be happening there.  But one thing for sure, I never see two ntpd processes with 4.2.4p4 in the toggle test and I always do with 4.2.8.

Thanks for your feedback.

I re-compiled the source code from http://bugs.ntp.org (with and without the ntpd/ntp_io.c patch), but I still get these log entries you reported. Maybe there will be a new release that will address the issue.

But for me the solution of running 4.2.8 with a few additional log entires still beats turning off ntp.

flatsixracer wrote:

 

Thanks for your feedback.

I re-compiled the source code from http://bugs.ntp.org (with and without the ntpd/ntp_io.c patch), but I still get these log entries you reported. Maybe there will be a new release that will address the issue.

 

But for me the solution of running 4.2.8 with a few additional log entires still beats turning off ntp.

Yeah, I guess you should add that ntpd-ntp_io.c patch for 4.2.8  (FWIW it's supposed to be already included in the 4.2.8p1-beta1).

At any rate I am glad this is not specific to my configuration :-)  That was getting me a little worried.

I did do some more research and I believe at least the -v error can be removed by using the ntpd-wrapper that comes with Mountain Lion (probably the other later OS installations too, didn't check).  It looks like the one shown on this page.  The sntp call in this newer version uses the (new) sntp -K (a history file specification, in this case /dev/null) and -s (set time with adjtime) options.  This of course does nothing to help all the rest of the log reports.

While I agree with you that the security fix is probably better than having a few system.log entries, it still remains to be verified whether those errors are insignificant enough so as to still let the clock keep proper time.  If not it's no better than just turning off ntp.  Being so hung up on these log "errors" I certainly haven't had the time (no pun intended) running the system with the 4.2.8 to verify the clock accuracy.

xyzzy-xyzzy wrote:

 

When you restart ntpd via the Date&Time preferences (toggle the "Set date and time automatically" checkbox), do a ps ax|grep ntpd on the terminal.  How many ntpd processes do you see?  Also what do you see in the system.log (using Console) when you restart ntpd?

(My system was rebooted after applying the fix.)

When I toggle the checkbox Terminal shows two processes. Console logs the same occurrences as in your post.

When I reboot after this experiment Terminal shows one process.

So what does it mean? Never stop your work to toggle date & time settings? Or is it worse than that?

See the last paragraph in my previous post.  At the moment I don't know what the implications are.  It's one of the reasons I posted this here.

Edit:

Just an afterthought -- the more I think about it the more I believe that the ntpd-wrapper must be changed since I think it's that sntp call that actually corrects the clock.  Since it's erroring out with the invalid argument using the "old" (current Snow Leopard) ntpd-wrapper I don't think there is any correction being done to the clock -- ever!

Can't edit my previous post, so,...

FYI: Just a quick addition for those who may not know what ntpd-wrapper is.  It (/usr/libexec/ntpd-wrapper) is the shell script invoked by /System/Library/LaunchDaemons/org.ntp.ntpd.plist.  ntpd-wrapper in turn invokes ntpd, the process you see in your process list.

ntpd-wrapper is specific to Apple and thus not something that is built when using the standard ntp sources from www.ntp.org (where all this ntp stuff comes from).   That's why I think it's slipping through the cracks here.

--- and now that I've said all this "out loud" I really am not sure how all this machinery works, i.e., where above I thought that the failure of sntp would not ever set the clock, I really now not sure what ntpd's role in all this is.  How do these two work together?  It's too late now, got to go to bed, my brain hurts! :-)

You are correct, good catch.

Changing the ntp-wrapper to use the new parameters, resolved the: "/usr/bin/sntp: illegal option -- v- " log entr,  but the others remain. I am not too worried about the IPV6_MULTICAST_IF messages, but I want to understand  the "mlockall(): Function not implemented" message. I may take a closer look at the code and compiler options, but this can quickly become a big project.

But for now (based on xyzzy-xyzzy's discovery). I updated the ntp 4.2.8 installer, with the corrected /usr/libexec/ntpd-wrapper script, so it can be updated by simply reinstalling the ntp 4.2.8 installer package.

--- ntpd-wrapper version > 4.2.6 (compared with patched OS X 10.9)

...

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

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

...

--- ntpd-wrapper version < 4.2.4

...

> 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

...

Ahh, so that's what "KoD" probably means. Thanks for researching that.

WZZZ, I notice in your logs that you don't have the sntp -v error I have in my log.  Then can I assume you are running on a system with a /user/libexec/ntpd-wrapper that looks like the one on this page?  Specifically the sntp line with the -K and -s arguments?  Maybe that change already exists in systems beyond Snow Leopard's ntpd 4.2.4p4.   I don't have anything beyond so I cannot check.

As for the mlockall() message, I did a little deeper investigation.   I think I found that  it comes from ntpd/ntpd.c in the ntpd sources.   The code sequence looks like this:

# if defined(HAVE_MLOCKALL)

        /*

         * lock the process into memory

         */

        if (!HAVE_OPT(SAVECONFIGQUIT) &&

            0 != mlockall(MCL_CURRENT|MCL_FUTURE))

            msyslog(LOG_ERR, "mlockall(): %m");

# else    /* !HAVE_MLOCKALL follows */

So if I am right I (like to) believe it's just a warning more-or-less since it doesn't change overall code flow and the locking failure doesn't cause problems .   Note that mlockall() is a valid function in Snow Leopard (declared in /usr/include/sys/mman.h) which is why HAVE_MLOCKALL is defined.  I am not sure why that mlockall() fails because I didn't dig deeper into understanding its call arguments.

flatsixracer wrote:

 

...<snip>...But for now (based on xyzzy-xyzzy's discovery). I updated the ntp 4.2.8 installer, with the corrected /usr/libexec/ntpd-wrapper script, so it can be updated by simply reinstalling the ntp 4.2.8 installer package...<snip>..

One more suggestion about your installer pkg.  I suggest you change the installer from requiring a forced logout to a forced reboot just for safety.

Just a thought.