After many years of deprecation while still shipping, ntpdate's days as a separate C program are numbered. I want to review alternatives and suggest next steps.
First, though, a quick review of why ntpdate is deprecated and will be removed. ntpdate serves two primary purposes today: 1) A diagnostic tool, particularly to help troubleshoot connectivity problems such as those introduced by firewalls. In this role, 4.2.7's sntp provides equivalent capability, including the ability to send queries from the reserved NTP UDP port 123. 2) One-shot clock synchronization, such as before starting step-phobic daemons. In this role, there are a plethora of alternatives, which I will cover below. ntpdate started decades ago as a stripped-down clone of the full NTP protocol from ntpd tailored for one-shot operation. In the intervening years, the protocol specification and the reference implementation in ntpd have improved in countless ways, yet ntpdate hasn't been maintained and so reflects a very old snapshot of the NTP protocol. Given the lack of attention and the duplication of code with ntpd, ntpdate has been deprecated for years. Its removal has not happened yet largely because it is still so widely used by init scripts, and there is no direct replacement as yet. In my eye, the biggest obstacle to its removal from the distribution is the creation of a shell script called ntpdate which emulates its functionality using one or more alternatives. Alternatives in the reference implementation distribution are: A) ntpd's ntpdate mode, invoked with the -q/--quit command-line option. In this mode of operation, ntpd does not detach from the terminal and daemonize, but runs interactively, and terminates after the clock is first synchronized. For example, a simplistic ntpdate shell script that would cover many init script uses is: #/bin/sh ntpd -gqc /dev/null $@ -c /dev/null causes the default ntp.conf file to be ignored in favor of the empty /dev/null "file". $@ passes any server DNS names/IP addresses on to ntpd, which treats them as if specified in ntp.conf with iburst. B) ntp-wait is a shell script installed alongside ntpd which uses ntpq repeatedly to wait for the first clock sync by the ntpd in normal daemon operation. The init scripts can thus start ntpd, then start any step-tolerant daemons, then use ntp-wait to block awaiting first clock sync, and finally start any step-sensitive daemons. C) ntpd's --wait-sync command-line option provides nearly identical capability to ntp-wait, with a slightly different approach. With --wait-sync specified, ntpd daemonizes a child process, but the parent procoess does not immediately return. Rather, it waits until either the daemon first synchronizes the clock, or a timeout expires. The exit code indicates which termination condition occurred. The init scripts can thus start any step-tolerant daemons, then start "ntpd --wait-sync 60", and finally start any step-sensitive daemons, which will not be started until the clock is synced or 60 seconds have elapsed. D) sntp provides a RFC-compliant, simple and quick one-shot SNTP client. This is a small, straightforward program implementing the Simple Network Time Protocol. As Harlan Stenn points out, this is appropriate for those who care more about setting the time quickly than setting it well. Any of the three prior alternatives (providing full NTP) are better in terms of minimizing the probability of post-startup clock steps by ntpd. On the other hand, for situations where code size or complexity must be minimized, sntp may be more attractive. Some bugs have been fixed in ntpdate in the 4.2.7 timeframe, and its query rate has been moderated to avoid triggering rate-limiting by ntpd where enabled using "restrict ... limited". I'm tempted to wait to remove ntpdate until after 4.2.8 is released as the next ntp-stable, so the last -stable version of the old ntpdate code is the best available. Meanwhile, if you have time and shell-script-fu, please feel free to take a shot at authoring a "newntpdate" script to replace it once the C code is excised. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
