Ntpd.service Could Not Be Found

[Vinnie Frevert]

Ihave a GTM 11.4.1 HF9 pool with no health monitor assigned. There is also no health monitor assigned to any of the servers ("members") in the pool. How do the pool and servers in the pool all have a green "Available" status if there are no health monitors? These servers have a service port of 123 (NTP). Is the GTM probing that port to get the "Available" status? The servers/members in question are not located on an LTM, so I don't see how iQuery could be at work here as mentioned in SOL5431.

I think I may have found the answer. In this case, stopping the NTP service on one of the servers resulted in it going unavailable/red in the GTM. This seems to indicate that the GTM is indeed making a connection to port 123 to the server. Additionally, with the NTP service still stopped on the server, I added a Gateway ICMP monitor to the server object in the GTM. While I could ping the server, the object was still red/unviable. This must suggest that as long as the port 123 connection was failing, any other monitors were not even considered.

I spend most of my time in LTM so I am always trying make comparisons between GTM and LTM. In LTM when you add a node (server), LTM automatically assigns an ICMP ping monitor to the object. If that doesn't succeed, then the object is always red. But in GTM, the base/default monitor for the object must be the service port you assign to it. So the GTM is quite different in that regard.

Using image builder, I see that my build has an ntpd server.

To shut that service down, I use '/etc/init.d/sysntpd disable' and '/etc/init.d/sysntpd stop' but it seems to get enabled again when I reboot.

I don't need an ntp server, just a client but there is no package called ntp, ntpd or sysntpd so how can I remove this package to use ntpdate instead?

Edit:

Specifically with imagebuilder, the options are more restricted as it is no real compiling, but just gluing components together.

But overriding the init script with a custom file should still be possible.

However, I still don't know how to remove it since I don't have it as a package.

I looked at the link you shared but I'm not sure how to use that with image builder.

Searching for 'config BUSYBOX_DEFAULT_NTPD' results in nothing found.

Yes, that's what I was thinking too.

In the second link you share, it looks like the sysntpd service controls the ntpd service but I don't see what I have to change to prevent the service from starting.

Yeah, that is for real compilation with toolchain.

Imagebuilder is just for gluing a simple firmware together, but you can't change package compile options. You should start using the full toolchain if you want deeper modifications to core components.

I'm looking at the sysntpd file and I think I would just have to edit what ever starts the ntpd service in this (the start ntpd line) then add this file into my build. I'm just not 100% sure which part to edit.

Commenting those lines out seems to be working. Even if I start the sysntpd service, no ntpd processes are showing up. Assuming that doesn't bork anything and sysntpd is not an essential service, which I think you mention it's not, this could work.

I bought a new Mac Mini two days ago, with High Sierra, and tried the above. When I did 'systemsetup -getnetworktimeserver' before doing the above I got "Network Time Server: time.apple.com", as expected. That was the previous contents of /etc/ntp.conf. When I then did the above set of instructions for my new config, my killall came back with "No matching processes were found" ??? Then I ran the 'sudo ntpd', then did the systemsetup -getnetworktimeserver' and got "Network Time Server: (null)". On my other two High Sierra system that comes back as "Network Time Server: mail.hprs.local".

BDAqua: regarding "ignored", MrHoffman's understanding about the range skew with ntp is the same as mine. That's why I set the Mac to only 4 minutes off from the Domain Controller in my test of Dec 18, 2018 8:08 PM, posted above, since the default setting of Maximum Tolerance for Active Directory on Windows is 5 minutes.

BUT! ... none of that matters. The helpful folks and LinuxQuestions.org found the answer to this puzzle. Mac DOES NOT use ntpd. Since High Sierra Mac uses timed. Read all about it here -anyone-got-the-time-how-high-sierra-has-changed-time-synchronisation/. Therefore, tools like ntpq and ntpdc won't work. There's nothing listening on the local host on the ports which these utilities use. Furthermore, this is a customized, stripped down version of timed, not the original, full-fledged version that runs on Unix. There are no parameters, commands or timedc program for interfacing. It does, however, use /etc/ntp.conf although I presume everything except the actual host name(s) is ignored.

Interestingly, that link author suggests taking "a careful look at" /var/db/timed/com.apple.timed.plist to investigate the state of timed, but I found that to be a binary file. If anyone knows how to look at that file, please advise.

although that doesn't seem to have made much difference. When I had the other servers and "iburst" and "prefer", etc. in there, the System Preferences > Date & Time > Set date and time automatically, showed all servers separated by commas, so perhaps my original conf file is no worse that this stripped down version.

The time server is a local Active Directory / Domain Controller, and it has a default Maximum Tolerance policy of 5 minutes. What happens if the difference is more than 5 minutes I don't recall. Nevertheless, to be safe, I tried your idea but setting the clock difference to 4 minutes. I 'watch'ed the time on both the AD/DC and Mac workstation, then went away for an hour. When I returned, the times were back in sync. So, yes, they synchronize. Good suggestion!

Since nptd is NOT running on the Mac, do you have any idea what is doing the synchronization? Is it a bad idea to actually run ntpd? Do you know whether the other ntp.conf settings (iburst prefer, fudge, restrict, ...) do anything at all? iburst is mentioned in the ntpd manpage. The ntp.conf manpage doesn't exist on the mac despite its being referenced in the ntpd manpage. The driftfile definitely never gets created.

Ordinarily, ntpd reads the ntp.conf configuration file at startup time in order to determine the synchronization sources and operating modes. It is also possible to specify a working, although limited, configuration entirely on the command line, obviating the need for a configuration file. This may be particularly useful when the local host is to be configured as a broadcast/multicast client, with all peers being determined by listening to broadcasts at run time.

Usually, the configuration file is installed in the /etc directory, but could be installed elsewhere (see the -c conffile command line option). The file format is similar to other Unix configuration files - comments begin with a # character and extend to the end of the line; blank lines are ignored.

ntpd has gotten rather fat. While not huge, it has gotten larger than might be desirable for an elevated-priority ntpd running on a workstation, particularly since many of the fancy features which consume the space were designed more with a busy primary server, rather than a high stratum workstation in mind.

Why is the connection refused? The firewall is not running. Another posting said I needed 'restrict 127.0.0.1' or the ntpq wouldn't work for the localhost. I've tried that, but the results are shown above.

You opine that it's not necessary "bad" to run ntpd, but would than not interfere with whatever is already doing the synchronizing? Going ahead and running ntpd doesn't seem to help with the ntpq problem although it then doesn't say "connection refused"; it times out instead.

Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker configuration file directive for other options.

To avoid this, most folks using ntpd will eventually learn to make a query to update the local time using ntpq (or ntpdate) before launching ntpd. Or launch ntpd with the -g option. Or the operating system can make that ntp query for the user, depending on the details of the ntp configuration within the local operating system configuration.

That's the normal and expected outcome of a well-behaved ntp environment, and not related to an out-of-range time. When the ntp server is receiving time values from lower-stratum time servers and these within its expected range, the local system time update frequency will be drifted more quickly or more slowly, to bring the system time toward the received time without ever causing the system time to change backwards. System clocks have ticks, and ntp adds or removes a few ticks from the larger batch of ticks associated with each clock update to drift the current clock time toward the time values being acquired directly or indirectly from the ntp stratum-0 reference time clock(s) in use.

3a8082e126