Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Troubleshooting NTP on Red Hat Linux

News NTP -- Network Time Protocol Recommended Links RHEL NTP configuration Changing timezone in RHEL6 from the command line Redhat Network Configuration RHEL handling of DST change
Configuration of Solaris NTP server Troubleshooting NTP on Solaris   ILO 3 NTP configuration   Humor Etc

Note: Some versions of Red Hat Linux do not propagate NTP setting you put during installation to Anaconda. In this case you need to set up NTP manually after first reboot.

Preliminary Steps

  1. Check if you have a correct timezone

    redhat.com How do I change my system timezone from the command line without using redhat-config-date?

    In order to change the timezone of your system you need to edit /etc/sysconfig/clock:

    #ZONE="America/New_York"
    ZONE="GMT"
    UTC=true
    ARC=false
    

    Note: If your system's BIOS has UTC set to true, then set UTC to true.UTC setting in the configuration file must always reflect your actual BIOS settings.

    ... ... ...

    Finally save the file /etc/sysconfig/clock and on next reboot the system time will be set to the defined timezone.

    For the time on the machine to reflect the change timezone we need to link the zoneinfo file to /etc/localtime. This can be done as follows :

    # ln -sf /usr/share/zoneinfo/Brazil/East /etc/localtime
    
    Now by typing the date command to display the time you should see if reflect the newly linked timezone :
    # date
    Thu Sep 30 10:06:23 BRT 2004
  2. Check if /etc/ntp/ntpservers contains NTP servers that you need and correct them if necessary (the default set are Red Hat NTP servers that might be not accessible because of firewall or proxy):

    vi /etc/ntp/ntpservers
  3. Run ntpdate to check if it will synchronize your clock with a time server. ntpd will not synchronize your clock with a time server if your system clock is significantly off NTP time.
    ntpdate -u 0.us.pool.ntp.org
  4. Check if ntpdis configured to start on the runlevels you work (typically 3 and 5).
    chkconfig ntpd on
  5. Try to start the ntpd daemon manually.
    service ntpd start

Note: The graphical user interface utility redhat-config-date (Red Hat Linux) or system-config-date (Fedora Core) may also be used to administer NTP.

Using ntpq -p command

The most useful command for querying any time server's status is "ntpq -p". You can query a remote time server for the same kind of information with "ntpq -p <hostname>".

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.firma.com    10.5.41.2      2 u  781 1024  377    2.003   -0.466   0.434
+ntp2.firma.com    10.5.41.3      2 u  984 1024  377   19.834    1.209   0.228
The first position in the output lines is a quick indicator of the status of the remote server. A "*" indicates the server to which you are currently synchronized. It may take some part of an hour before your server considers itself synchronized. A "+" is a candidate to take the leading role if the current server becomes unsuitable for some reason.

The labeled columns for this are:

remote
The IP address or DNS name of the remote server
refid
An identification of the type of the reference clock.
st
The "stratum" or level of the server: for almost all systems, 2 is great. Your local system will have a higher number.
t
The type of service. Your setup will show "l" for local on your local system, or "u" for "unicast" for communicating with remote servers.
when
This is the number of seconds since the server was last heard from. After a couple of minutes of operation your server should start to report numeric values here.
poll
Current polling interval in seconds. When remote servers are responding, "when" should be no greater than "poll".
reach
This and the remaining fields are important indicators of the health of your local server, your remote servers, and their communication. This field is really a bit array indicating whether responses have been received to your local server's eight most recent requests. The value starts at 0. If your local server is receiving responses to all its requests, it will go to 1, then 3, then 7. The display is in octal, so 377 is the maximum value. Anything less indicates that either your local server recently started or some requests did not receive responses.
delay
Recent average roundtrip time in milliseconds from request to response.
offset
Estimated differential between your system clock and this time server's clock, in milliseconds. You may consider this the "bottom line" on the accuracy of your system clock. NTP can usually drive this down to the level of the jitter or less.
jitter
A measure of the variability of the delays between request and receipt of a response, in milliseconds. High jitter tends to limit your server's ability to synchronize accurately.

Using tcpdump

You can easily check if packets are going out from your system and coming back to your box using tcpdump. NTP uses port 123, so you might issue a command like this as root:

  # tcpdump udp port 123

Allow it to monitor traffic for up to an hour. You should see packets going out to your time servers port 123 (ntp) and replies coming back from each of them. Your local UDP port will probably also be number 123. Kernel firewalling (ipchains or iptables) can prevent synchronization from working even if the servers are replying to your system's requests.

If you see packets coming in from the remote time servers, but ntpq indicates your server is not seeing them, then be sure to look at your ipchains/iptables configuration

Also check the system log for configuration messages from ntpd.

Using syslog

Your ntpd will log various events through your system's syslog facility. This typically means the messages will show up in /var/log/messages, in lines containing the string "ntpd". Configuration problems are reported here. If your local server steps the time ahead or back suddenly, it will report that here also with a message such as: time reset -6.394626 s.

Be careful if your clock is ahead of time

You should be careful adjusting your clock if it is significantly ahead of the actual time. You can use it to prevent ntpd from making large sudden adjustments to your system clock while the system is running, and to make sure the system clock never jumps backward in time. The NTP FAQ suggests doing the following steps if you can take your server down for a little while:

  1. Shutdown;
  2. Set the BIOS clock;
  3. Restart.

For systems with clocks ahead of real time, plan to leave the system off until real time catches up with its internal time when it was shut down. Since the system clock is initialized from the BIOS clock, this prevents the system clock from jumping back while your system is running.

For systems with clocks ahead of real time, plan to leave the system off until real time catches up with its internal time when it was shut down.

Recall that Linux can be configured to interpret the BIOS time as either local time or GMT (UTC). You can infer the configuration by comparing output from the "date" command with the BIOS clock time.

If case BIOS is configured with UTC time, Linux can automatically adjust time to summer time in spring and winter time in autumn.

If case BIOS is configured with UTC time, Linux can automatically adjust time to summer time in spring and winter time in autumn.

See RHEL handling of DST change


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Dec 01, 2015] HowTo Verify My NTP Working Or Not

by Vivek Gite on March 25, 2010 last updated November 29, 2015

... You can use any one of the following program to verify ntp client configuration:

  1. ntpq - standard NTP query program
  2. ntpstat - show network time synchronisation status
  3. timedatectl - show or set info about ntp using systemd

ntpstat command

The ntpstat command will report the synchronisation state of the NTP daemon running on the local machine. If the local system is found to be synchronised to a reference time source, ntpstat will report the approximate time accuracy.

You can use the exit status (return values) to verify its operations from a shell script or command line itself:

Type the command as follows:
$ ntpstat
Sample outputs:

synchronised to NTP server (149.20.54.20) at stratum 3
   time correct to within 42 ms
   polling server every 1024 s

Use the echo command to display exit status of ntp client:
$ echo $?
Sample outputs:

0

ntpq command

The ntpq utility program is used to monitor NTP daemon ntpd operations and determine performance. The program can be run either in interactive mode or controlled using command line arguments. Type the following command
$ ntpq -pn
OR
$ ntpq -p
Sample outputs:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*dione.cbane.org 204.123.2.5      2 u  509 1024  377   51.661   -3.343   0.279
+ns1.your-site.c 132.236.56.252   3 u  899 1024  377   48.395    2.047   1.006
+ntp.yoinks.net  129.7.1.66       2 u  930 1024  377    0.693    1.035   0.241
 LOCAL(0)        .LOCL.          10 l   45   64  377    0.000    0.000   0.001

The above is an example of working ntp client. Where,

  1. -p : Print a list of the peers known to the server as well as a summary of their state.
  2. -n : Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.

A note about timedatectl command

If you are using systemd based system, run the following command to check the service status
# timedatectl status

systemd-timesyncd configuration

If NTP enabled is set to No. Try configuring by editing /etc/systemd/timesyncd.conf file as follows:
# vi /etc/systemd/timesyncd.conf
Append/edit [Time] as follows i.e. add time servers or change the provided ones, uncomment the relevant line and list their host name or IP separated by a space (default from my Debian 8.x server):

[Time]
Servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Save and close the file. Finally, start and enable it, run:
# timedatectl set-ntp true
# timedatectl status

[Oct 26, 2013] RHEL handling of DST change

Most server hardware clocks are use UTC. UTC stands for the Universal Time, Coordinated, also known as Greenwich Mean Time (GMT). Other time zones are determined by adding or subtracting from the UTC time. Server typically displays local time, which now is subject of DST correction twice a year.

Wikipedia defines DST as follows:

Daylight saving time (DST), also known as summer time in British English, is the convention of advancing clocks so that evenings have more daylight and mornings have less. Typically clocks are adjusted forward one hour in late winter or early spring and are adjusted backward in autumn.

DST patch is only required in few countries such as USA.Please see this wikipedia article.

Linux will change to and from DST when the HWCLOCK setting in /etc/sysconfig/clock is set to -u, i.e. when the hardware clock is set to UTC (which is closely related to GMT), regardless of whether Linux was running at the time DST is entered or left.

When the HWCLOCK setting is set to `--localtime', Linux will not adjust the time, operating under the assumption that your system may be a dual boot system at that time and that the other OS takes care of the DST switch. If that was not the case, the DST change needs to be made manually.

Note:

EST is defined as being GMT -5 all year round. US/Eastern, on the other hand, means GMT-5 or GMT-4 depending on whether Daylight Savings Time (DST) is in effect or not.

The tzdata package contains data files with rules for various timezones around the world. When this package is updated, it will update multiple timezone changes for all previous timezone fixes.

[Sep 21, 2012 ] How to Configure NTP in a RHEL-CentOS Vmware Guest

FATMIN
Successful time keeping in a Virtual Machine can be a bit confusing. At times I have been told to use Vmware Tools to sync time between the Guest and the Host, and at time I have been advised to avoid this functionality and use NTP. The following information is direct from a VMware KB article (updated, 4/16/2010) so I am going to follow their lead on this and use NTP exclusively.

First off VMware advises using the NTP service to keep time in sync, but it suggests using an additional kernel parameter that you add to your grub.conf. See the KB Article for more info on how to do this.

Note that there are no additional params needed for 5.4

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

Also, inside the ntp.conf the following line should be added to the top of the file.

tinker panic 0 
This configuration directive instructs NTP not to give up if it sees a large jump in time. This is important for coping with large time drifts and also resuming virtual machines from their suspended state.

It is also important not to use the local clock as a time source, often referred to as the Undisciplined Local Clock. NTP has a tendency to fall back to this in preference to the remote servers when there is a large amount of time drift.

An example of such a configuration is below. You should comment out both lines.

server 127.127.1.0 
fudge 127.127.1.0 stratum 10 

Also, if you are using ntp, you want to make sure that you disable Vmware tools time sync. You can do so with the following command via the guest OS.

[ Sep 21, 2012] Configuring the NTP Daemon by Ed Halley

...Red Hat Linux comes with a sample /etc/ntp.conf, but if you just want your machine to synchronize with a public server, I recommend removing that file and starting with a far simpler script. Remove the existing file and create one that looks like the following.

# A very simple client-only ntp configuration.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10 
driftfile /etc/ntp/drift
restrict default ignore
restrict 127.0.0.0 mask 255.0.0.0
authenticate no

Choose your preferred NTP servers. Note that some servers are not available to the public, and some servers are too busy to handle new requests. Please do your homework in choosing appropriate servers that are geographically near you, and which will accept new public connections, and whether you must obtain their permission first.

You should select two or three servers for best results. For each server you find, discover its hostname and its fixed numerical address. Then add lines like the following to the /etc/ntp.conf file you created above.

server ntp5.someserver.etc
restrict 123.123.123.123 nomodify  # ntp5.someserver.etc

(The over-simplified Red Hat Linux time and date settings application allow a single-server configuration, but usually mangles the lines in the file, unfortunately, so don't use that utility once you've edited your own /etc/ntp.conf manually.)

Next, a separate ticker file must be created that lists the servers. The following command will read the /etc/ntp.conf file you've made, and create the proper list of servers for the ticker file. This finds the hostnames listed on lines beginning with 'server', except for the initial 127.127.1.0 local clock, and lists them in the ticker file.

$ su -
# awk '/^server/ {print $2}' /etc/ntp.conf | grep -v '127.127.1.0' > /etc/ntp/step-tickers

Before starting the service, roughly synchronize your clock using one of the servers with ntpdate. Ensure your configuration is set to run the NTP daemon ntpd to track and alleviate clock drifting.

$ su -
# chkconfig --list ntpd
ntpd        0:off   1:off   2:off   3:off   4:off   5:off   6:off
# ntpdate -u ntp5.someserver.etc
 9 Dec 15:15:15 ntpdate[12345]: step time server 123.123.123.123 offset 7.879896 sec
# chkconfig --level 345 ntpd on 

If your system clock is likely more than a few minutes off, it is best to shut down as many applications as possible before performing gross clock corrections. Some programs may have bugs which cause them to lose data or crash. A minimal environment such as running at runlevel 1 (single user mode) is the ideal situation for drastic clock changes.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July, 28, 2019