Christopher Metter put forth on 10/31/2010 1:51 PM:
To sum it up: Config with packet ntp installed runs properly and I still think that ntpdate throws the errors. Even system Startup is faster without it. Its 60seconds vs ~18seconds on rc2.d startuptime.
ntpdate is a mostly, to me, a command line utility. It is not a daemon. If installing the package "ntpdate" is causing problems at boot, it is very likely that your Linux distribution has an ntpdate install script that is sticking an ntpdate command in rc.local or some other place that causes it to run at boot. When this occurs, it's probably tying up the socket when ntpd tries to grab it. Install ntpdate again, and afterward, check rc.local and the rc*.d directories for a script that is running ntpdate at startup. Remove the reference to the script or command once you locate it.
ntpdate is useful for a sysadmin to do a manual check or set of the local clock against a specified ntp time source (possibly different from those configured for use by ntpd). It should not interfere with ntpd, at least not when using the query only switch. Debian Linux, for example, in my experience, doesn't have this problem you are experiencing while both ntpd and ntpdate are installed. I've never had a problem with it.
If I aint wrong, my system time is still accurate. And the problem is solved, or did I miss something?
If you never need to use ntpdate then I guess you could say your problem is solved. For me, personally, I use ntpdate specifically as a sanity check on occasion against ntpd to make sure what the latter is doing or reporting is accurate. ntpq -p doesn't necessarily guarantee that.
If you never have used ntpdate from the prompt in the past, and never intend to, then I guess you're good to go. Carry on. ;)
-- Stan