ntpd -g does not sync the clock

From ntpd man page

If time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the clock will be set to the server time regardless of the chip time.

I have done small experiment to test -g option with ntpd. First I changed the system clock time to some old time with date command.

date -s 2021.06.15-19:10:21

After that I created small /etc/ntp.conf file with below information

driftfile  /etc/ntp.drift
logconfig =syncstatus
server time.google.com minpoll 3 maxpoll 4

After that I ran ntpd with below command

ntpd -g -n -4 -c /etc/ntp.conf &

Please note that my ntp.drift file was empty.

I see no change in the system time , infact ntp status shows that clock is not synchronized.

GW:/# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
    time2.google.co .GOOG.           1 u    -   64    1    0.000   +0.000   0.000


Clock is not synchronized, stratum 16, reference is INIT
frequency is +0.000 Hz, precision is -19
reference time is (no time),
clock offset is +0.000000 msec, root delay is 0.000 msec
root dispersion is N/A

Can someone please help me. Did I missed any configuration or some other data.

Apart from this I have one small question

Does ntp clock need to be synchronised for ntp authentication? If ntp clock is not synchronised then in that case will ntp server authentication pass.

Edit:

Below are the logs come when I start ntpd

GW:~/var/log# cat ntpd.log
15 Jun 19:21:03 ntpd[14560]: Listen and drop on 0 v4wildcard 0.0.0.0:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 1 lo 127.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 2 srcr2 192.168.0.2:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 3 log0 1.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listening on routing socket on fd #20 for interface updates
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

Update:

@John I have done what ever you suggested but still I see same issue

GW:~/var/log# systemctl status ntpd
ntpd.service - NTPD daemon


Loaded: loaded (/etc/systemd/system/ntpd.service; disabled;   vendor  preset: enabled)
Active: active (running) since Fri 2021-07-09 08:17:46 UTC; 6min ago
Process: 21151 ExecStart=/bin/sh -c /sbin/ntpd -g  >> /var/log  /ntpd.log 2>&1  (code=exited, status=0/SUCCESS)
Main PID: 21153 (ntpd)
CGroup: /system.slice/ntpd.service
       └─21153 /sbin/ntpd -g
       

cat /etc/ntp.conf 
 # use a random selection of 4 public stratum 2 servers
 # see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
 #restrict default nomodify notrap noquery
 #restrict default noquery

logfile /var/log/ntpd.log
driftfile  /etc/ntp.drift
logconfig =syncstatus

server time1.google.com iburst
server time2.google.com iburst
server time3.google.com iburst
server time4.google.com iburst
#tried pool time.google.com also


GW:~/var/log# ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
1  8426  9014   yes   yes  none    reject   reachable  1
2  8427  9014   yes   yes  none    reject   reachable  1
3  8428  9014   yes   yes  none    reject   reachable  1
4  8429  9014   yes   yes  none    reject   reachable  1

GW:~/var/log# ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time1.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time2.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time3.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time4.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000


GW:~/var/log# cat ntpd.log
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 0 v6wildcard [::]:123
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 1 v4wildcard 0.0.0.0:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 2 lo 127.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 3 srcr2 192.168.0.2:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 4 log0 1.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listening on routing socket on fd #21 for interface updates
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

GW:~/var/log#

Can you please check once. Did I missed anything?

Update

Pasting ntpd association output

GW:/# ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 47211  9014   yes   yes  none    reject   reachable  1
  2 47212  9014   yes   yes  none    reject   reachable  1
  3 47213  9014   yes   yes  none    reject   reachable  1
  4 47214  9014   yes   yes  none    reject   reachable  1

GW:/# GW:/#

 GW:/# ntpq -c "rv 47211"
 associd=47211 status=9014 conf, reach, sel_reject, 1 event,   reachable, 
srcadr=time1.google.com, srcport=123, dstadr=192.168.0.2,  dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,   rootdisp=0.107,
refid=GOOG, reftime=e4a0073d.cba4777a  Mon, Jul 19 2021 14:14:21.795,
rec=e4a0073d.cba4777b  Mon, Jul 19 2021 14:14:21.795, reach=017,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=347,
flash=400 peer_dist, keyid=0, offset=+0.000, delay=0.000,
dispersion=15937.500, jitter=0.000, xleave=0.033,
filtdelay=  2833222 2833222 2833222 2833222 2833222 2833222 2833222 2833222,
filtoffset= +141661 +141661 +141661 +141661 +141661 +141661 +141661 +141661,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

Normally after allowing NTP through any firewall, the first few packets are processed (increasing reach), a system peer is selected, and the initial step fixes the time. This system has reachable peers but rejected them all, which is odd.

After reviewing readvar output, rootdelay=0.000 doesn't make sense. Remote over the internet, cannot be zero. Possibly why you got a flash word of distance threshold exceeded.

A theory from IRC is that NTP packets are being mangled by some middlebox. Which if true would be bad as it apparently broke NTP. ntpd applies dscp to its packets but ntpdate does not. Try dscp 0 in ntp.conf Ask around if differentiated services aware boxes are in the path. Take a packet capture (tcpdump) of NTP packets and look at it in Wireshark. See if it can dissect both any DSCP fields, wrapping NTP packets with NTP timestamps.

Also study ntpd in an entirely different network to contrast what it looks like when working. ntpd can run on anything, so maybe a VM on your workstation.

My original answer with a critique of the config follows.

Your reach recorded there is only 1. Wait 3 minutes after starting ntpd. Takes some time to get the first couple packets returned.

Regarding your configuration:

server time.google.com minpoll 3 maxpoll 4

Consider adding iburst to your server and pool lines. Initial burst at startup of several packets with a short delay.

I am not convinced configuring minpool and maxpool is a good idea, neither is Red Hat. Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.

Need more NTP servers, ideally 4 for detecting falsetickers with n+1 redundancy. Google public NTP has 4 frontends, which you can use with either the pool directive or multiple server lines. Feel free to add other NTP services as a second opinion, like 2.pool.ntp.org. (However you will have a messy leap second smear if your NTP servers don't agree on that.)

No, public NTP services do not require NTP authentication. Authentication is not your problem, allowing large steps and tweaking the poll rate is.

My suggested change for the server line is more like this:

pool time.google.com iburst

As to how you're starting ntpd:

ntpd -g -n -4 -c /etc/ntp.conf &

-g option is necessary to fix such a large offset of many hours, keep it. Allows infinite step once at start. Normally, large offset causes ntpd to panic. Use -g in any script that starts ntpd, so time will be fixed at boot.

I don't see the purpose of no fork plus shell backgrounding. For starting in the background, I use the system's service manager or init script. For example, a ntpd.service unit for Linux with systemd.

Delete -4. Google is IPv6 capable.

If you wish to set the time once and exit, the -q option is useful. For interactive use when troubleshooting, normal operation is leaving ntpd running. Do not use ntpdate, which is obsolete.

ntpd -g -q