Yes and no ntpd is full time and ntpdate only runs until the time is set. They're in essence the same daemon and when ntpdate starts it sees ntpd and shuts itself down.
Not quite true. "ntpdate" checks the time on an NTP server just once, and then forcefully changes the local system time to whatever result it got from the server, regardless of what that result was and with no sanity checks. If the server is 10 years off from the local system time, the local system time *still* gets smacked instantly to match the server. It just happens to use the NTP protocol to communicate with an NTP server.
"ntpd", on the other hand, checks two or more servers initially every 64 seconds. After several (8 or more, usually) queries, when it feels that it has a sufficiently solid idea of what the "correct" time is Out There, it begins slowly sliding the local system clock to match that "correct" time without making any sudden moves that might confuse local applications and/or server processes.
Also, ntpd provides very high precision, and it will not adjust the system clock (it will exit and report an error instead) if the local time if off by more than 120 seconds. Given that my server clocks are usually less than 0.01 seconds away from the "correct" time and that theoretically ntpd is capable of maintaining an error of less than 0.0000001 seconds, you can see that it considers *two minutes* as an ungodly, horrendous, utterly unacceptable misconfiguration.
If at all possible, one should avoid using ntpdate at all. Simply run ntpd on one box, set all others to adjust their time to that server (which also uses NTP), and be done with it. After the initial half-hour (approximately) startup period, it all "just works" beautifully.
Cheers,
-- Rodolfo J. Paiz rpaiz@xxxxxxxxxxxxxx http://www.simpaticus.com
