My first post and first visit, so hello. I have been asked to see if one of our Linux boxes can have it's time sync automatically because the person who built the system has told our staff it cannot be done. To me that raised some flags because although I am no Linux expert, I just thought, that's impossible.
So I did a bit of research before seeking help form the experts before I try anything.
First thing I came across was the command,
ntpdate pool.ntp.org <- which would sync the box to public NTP servers
Then this command
crontab -e
0 4 * * * /usr/sbin/ntpdate pool.ntp.org <- which would create a schedule to sync every night at 4am
Am I on the right track? We are using Red Hat 5.2 (tikanga), and I don't want to screw anything up, like I said I'm familiar with Linux to some point but no expert. Boils down to wanting this system to synchronize daily with EST Time server.
Thank you for any suggestions and tips or tricks for a linux newb.
That's almost exactly what we have, except instead of syncing every night at 4am, we do so every boot.
Generally there's no such thing as an 'EST time server'. Your system clock is supposed to be set to time zone 0, Greenwich mean time, and the local time zone controlled by the TZ variable, or a profile file, or other means. If your admin set the clock itself to local time, I'm not sure what to do.
---------- Post updated at 09:17 AM ---------- Previous update was at 09:10 AM ----------
Actually I do know what to do. Run ntpdate -q pool.ntp.org and see if it wants to advance the time 9 hours or something crazy, or whether it's just off by minutes or seconds. -q tells it not to set the time, just query.
Firstly, my apologies for not enclosing my code samples within the proper tags, corrected now.
Thank you Corona688 for the reply. I will do as you mentioned, our system rarely reboots so having our at boot time would not work in my case anyway. Thank you for the explanation of time zone offsets, I never knew this with Linux. Appreciate your input.
So mark54g how would your suggestion of running ntpd be utilized on our system then to automatically keep the system continually synchronized because right now they are having to on monthly basis resync cause it drifts 3-4 minutes out. Using the same kind of crontab command to set up the scheduling? Thanks.
Absolutely not using cron. ntpd is a daemon. It is constantly running and should be set up via an appropriate ntp.conf file to ensure that it stays within milliseconds, not minutes. You may need a step tickers and drift file, as well as statistics, but you can, with a good time source, be within about 20 milliseconds over the internet without much issue.
Personally, I would suggest you get a master clock, but if you don't need sync to be that tight, you can sync to the internet as long as there are not a lot of machines.
You should not have to download it, but configure it as instructed.
Essentially, you will end up, with the appropriate configuration and init scripts, set up your server to slew the clock toward the appropriate time so that you are within a margin of error. The speed/latency to the internet does not actually matter as much as the differential between answers, and you should be polling those upstream lower stratum servers every few minutes to make sure you are not out of the ballpark. Then, the algorithm for ntp will be able to "Train" your clock on the server to stay within acceptable ranges by use of a drift file.
Thank you mark54g, I have set up ntpd and hopefully that should take care of our problem. The service was not running and when I looked it up it was only checking locally, so added a known NTP that were using for our manual execution.
Appreciate you pointing me in the right direction.
No problem. Using ntpdate to slam a clock at intervals with cron seems like hammering screws with the screwdriver is right there in your tool kit. The right tool for the job should be to use the daemon.
ntp just seems so complicated for what it does... set the time. It's also rather undeterministic. "update clock on boot if possible" seems preferable to "set clock whenever ntp feels like it", particularly when it's changing not just seconds, but days, months, and years.
But I suppose I don't need the clock accurate down to milliseconds, I usually just want things to stop flashing 12
for test & dev boxes here anything close to the real time is fine. For production - no.
The legal department would have a cow if we were not spot on with time. We are a publically regulated utility. This is true in finance, utilities, etc. - any place where customers like to sue for their own negligence. (or the company's)
Properly configured NTP will not be as convoluted as you seem to make it out to be. I worked at an exchange, and when we needed precise time, we got it down to 300us. If and when we needed more, PTP was being looked into
It is not un-deterministic because you do NOT want to alter the clock regularly. There is a reason that it is preferable to slew the clock. Each crystal oscillates differently, and the factors that influence this can be electrical or thermal among others. The way that NTP can correct this is to have a proper drift file as well as a stepping file. Then, the daemon can check values based on the past, even through a reboot.
Normally, on a reboot, a clock would have too much indeterminism to function properly for an exchange system without such tools. The clock would vary wildly for the first few minutes of operation. After the configuration was updated, the machine was usable significantly faster.
This may not be a concern to you, but as modern clusters need to sync'd regularly to function properly, it is hitting more people than it used to.
Thank you for that explanation. That there's real applications where timing is important enough for thermal drift to cause software errors in realtime is bit of an eye opener.
No problem. You have your specialties. This one is just one that has been hammered home to me on repeated occasion. Essentially, using things like minpoll and maxpoll you can set how often the lower stratum clock needs to/should be checked.
At my last company, I actually updated/rewrote the default init script for ntpd because we wanted to slam clocks that were outside of the acceptable tolerances, since they would otherwise not be usable. It also on start/status would check the offset from the 2 upstream stratum 1 clocks in their regions to show how far off they were from their lower stratums.
GPS is widely used as a medium for a stratum 1 clock because of the high level of accuracy and precision.
