Volker Kuhlmann wrote:
eh? -q does the query without setting the clock ...
You meant -u?
Perhaps, depends on what you mean by *use*. Retrieving the time, or setting the box's clock as well? You're correct though that ntpdate refuses to set the time if there's an ntpd running IIRC. I doubt that has to do with ports though.
Volker
Hi Volker,
Mine was the original post, and it made perfect sense in the context it was written, which was how to set up a time server for a local network. ntpdate -q is pretty meaningless in this context. I must admit I'd not seen the -u flag before, and you're absolutely correct on that one.
By default, both ntpd and ntpdate use port 123, so attempting to run ntpdate (without -u) when ntpd is running will result in an error as the port already has a process listening on it. ntpd is far, far more accurate than ntpdate, so it's really only useful to use ntpdate in the manner I described in my original post, which is to correct major inaccuracies at startup time, before time sensitive processes ( especially all those user initiated commands like ls! ), are started. ntpd handles drift and small changes very gracefully, but it would take weeks to fix an error of a few hours!
Steve.
PS. It really is a bit meaningless to use any ntp server abroad, as in my suggestions above (:
