NTP synchronized: no

Shaheen Bakhtiar shashaness at hotmail.com
Wed Sep 9 19:17:13 UTC 2015



> On Sep 9, 2015, at 11:00 AM, Rick Stevens <ricks at alldigital.com> wrote:
> 
> On 09/09/2015 10:37 AM, Patrick Dupre wrote:
>> Still the same (always as root)
>> 
>>  journalctl -u chrony -b
>> -- Logs begin at Fri 2014-05-02 02:14:24 CEST, end at Wed 2015-09-09 19:34:53 CEST. --
>> 
>> 
>> after  systemctl restart chronyd
>> 
>> systemctl list-unit-files | grep chrony
>> chrony-wait.service                         disabled
>> chronyd.service                             enabled
>> 
>> 
>> chronyd.service - NTP client/server
>>    Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
>>    Active: active (running) since Wed 2015-09-09 19:31:53 CEST; 4min 23s ago
>>   Process: 6933 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=0/SUCCESS)
>>   Process: 6929 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
>>  Main PID: 6931 (chronyd)
>>    CGroup: /system.slice/chronyd.service
>>            └─6931 /usr/sbin/chronyd
>> 
>> Sep 09 19:31:53 Homere chronyd[6931]: chronyd version 1.31.1 starting
>> Sep 09 19:31:53 Homere chronyd[6931]: Frequency -15.841 +/- 0.025 ppm read from /var/lib/chrony/drift
>> Sep 09 19:31:53 Homere systemd[1]: Started NTP client/server.
> 
> Is there a reason you're starting ntp? You don't need it with chronyd.
> Perhaps that's the issue--they're fighting each other. Try stopping and
> disabling whatever is starting that "NTP client/server" thing, then
> restart chronyd.
> 
> You either use ntpd or chronyd, not both. Since they'll both try to camp
> out on port 123, there's going to be conflicts if they're both running.
> 
>>> On 09/09/2015 10:04 AM, Patrick Dupre wrote:
>>>>> On 09/09/2015 08:17 AM, Patrick Dupre wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> According to the domain administrator, the port is open.
>>>>>> Could it be an issue with the firewall?
>>>>>> 
>>>>>> iptables -L |grep udp
>>>>>> ACCEPT     udp  --  anywhere             224.0.0.251          udp dpt:mdns ctstate NEW
>>>>>> ACCEPT     udp  --  anywhere             anywhere             udp dpt:ipp ctstate NEW
>>>>>> ACCEPT     udp  --  anywhere             anywhere             udp dpt:ipp ctstate NEW
>>>>>> 
>>>>>> ntp is on the port 123
>>>>>> 
>>>>>> In zone internal I checked ntp
>>>>>> 
>>>>>> It is all I need?
>>>>> 
>>>>> I don't think that's necessary. The firewall rules affect incoming
>>>>> connections (it's a stateful firewall...if you initiate the connection,
>>>>> the reply is permitted). I'd suggest looking at the system logs at this
>>>>> point to see what's going on, e.g.:
>>>>> 
>>>>> 	journalctl -u chrony -b
>>>>> 
>>>>> Perhaps that'll give you some hints.
>>>>> 
>>>> journalctl -u chrony -b
>>>> -- Logs begin at Fri 2014-05-02 02:14:24 CEST, end at Wed 2015-09-09 19:02:05 CEST. --
>>> 
>>> Well, that's interesting! Looks like chrony never started! Try, as root,
>>> 
>>> 	systemctl start chronyd
>>> 
>>> Wait for a few minutes, then check journalctl again. If you see data in
>>> the logs then, as root:
>>> 
>>> 	systemctl list-unit-files chrony*
>>> 
>>> See if you get output like this:
>>> 
>>> 	UNIT FILE           STATE
>>> 	chrony-wait.service disabled
>>> 	chronyd.service     enabled
>>> 
>>> If you see "chronyd.service disabled", then as root:
>>> 
>>> 	systemctl enable chronyd
>>> 
>>> to make sure it starts next time.
>>> ----------------------------------------------------------------------
>>> - Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
>>> - AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>>> -                                                                    -
>>> ----------------------------------------------------------------------
>>> --
>>> users mailing list
>>> users at lists.fedoraproject.org
>>> To unsubscribe or change subscription options:
>>> https://admin.fedoraproject.org/mailman/listinfo/users
>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>>> Have a question? Ask away: http://ask.fedoraproject.org
>>> 
> 
> 
> -- 
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
> - AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> -                                                                    -
> -  You know the old saying--any technology sufficiently advanced is  -
> -               indistinguishable from a Perl script                 -
> -                                 --Programming Perl, 2nd Edition    -
> ----------------------------------------------------------------------
> -- 
> users mailing list
> users at lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org



Interesting….

Just tested this on a somewhat brand new install of FC22 (fully updated) and I’m getting the same results. I do have port 123 open on the firewall INBOUND as well as the server (that is any udp port can connect to my machines at port 123) but based on the TCPDUMP I just did it looks like chrony is connecting using an unprivileged port, which most likely means (and I’ve come across a few articles that say as much) the firewall rule needs to allow incoming UDP port 123 to ANY port on the server.

I can see why firewall admins would be VERY apprehensive about doing this, and I’m not in the office so I don’t want to play with my firewall rules remotely. I’ll be in tomorrow and I’ll test my theory by opening source port 123 to any port and see if this solves the problem.

OT: If it does, I would have to agree with the few articles I’ve read out there regarding this. IT is a BAD implementation. It all but forces on to simply buy a GPS unit or time server and house it on site. 

http://superuser.com/questions/141772/what-are-the-iptables-rules-to-permit-ntp <http://superuser.com/questions/141772/what-are-the-iptables-rules-to-permit-ntp>
http://superuser.com/questions/762579/why-does-ntp-require-bi-directional-firewall-access-to-udp-port-123 <http://superuser.com/questions/762579/why-does-ntp-require-bi-directional-firewall-access-to-udp-port-123>

[root at smtp ~]# systemctl status chronyd.service 
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2015-09-09 11:35:34 PDT; 25min ago
  Process: 5722 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 5718 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 5720 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─5720 /usr/sbin/chronyd

Sep 09 11:35:34 smtp.inksystemsinc.com systemd[1]: Starting NTP client/server...
Sep 09 11:35:34 smtp.inksystemsinc.com chronyd[5720]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCD...ECHASH)
Sep 09 11:35:34 smtp.inksystemsinc.com chronyd[5720]: Generated key 1
Sep 09 11:35:34 smtp.inksystemsinc.com systemd[1]: Started NTP client/server.

[root at smtp ~]# timedatectl
      Local time: Wed 2015-09-09 12:02:28 PDT
  Universal time: Wed 2015-09-09 19:02:28 UTC
        RTC time: Wed 2015-09-09 19:02:34
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2015-03-08 01:59:59 PST
                  Sun 2015-03-08 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2015-11-01 01:59:59 PDT
                  Sun 2015-11-01 01:00:00 PST

[root at smtp ~]# chronyc -n sources
210 Number of sources = 8
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 208.75.88.4                   0   7     0   10y     +0ns[   +0ns] +/-    0ns
^? 50.116.38.157                 0   7     0   10y     +0ns[   +0ns] +/-    0ns
^? 107.170.242.27                0   7     0   10y     +0ns[   +0ns] +/-    0ns
^? 131.107.13.100                0   7     0   10y     +0ns[   +0ns] +/-    0ns
^? 2604:8800:100:65::2           0   6     0   10y     +0ns[   +0ns] +/-    0ns
^? 2a00:1630:66:ea::e82a         0   6     0   10y     +0ns[   +0ns] +/-    0ns
^? 2600:3c03::f03c:91ff:feae:3952   0   6     0   10y     +0ns[   +0ns] +/-    0ns
^? 2602:ffa1:200::3              0   6     0   10y     +0ns[   +0ns] +/-    0ns




[root at smtp ~]# tcpdump port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s2f0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:20:35.435351 IP smtp.inksystemsinc.com.59841 > repos.lax-noc.com.ntp: NTPv4, Client, length 48
12:20:36.780107 IP smtp.inksystemsinc.com.58673 > name1.glorb.com.ntp: NTPv4, Client, length 48
12:20:39.177934 IP smtp.inksystemsinc.com.48109 > time-b.nist.gov.ntp: NTPv4, Client, length 48
12:20:42.249166 IP smtp.inksystemsinc.com.46548 > time-c.nist.gov.ntp: NTPv4, Client, length 48
12:24:21.798506 IP smtp.inksystemsinc.com.38782 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:21.999909 IP smtp.inksystemsinc.com.39560 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:23.009871 IP smtp.inksystemsinc.com.47688 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:23.211233 IP smtp.inksystemsinc.com.46101 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:23.813548 IP smtp.inksystemsinc.com.43697 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:24.019143 IP smtp.inksystemsinc.com.35847 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:25.044904 IP smtp.inksystemsinc.com.33086 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:25.248017 IP smtp.inksystemsinc.com.52609 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:25.842556 IP smtp.inksystemsinc.com.59576 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:26.049297 IP smtp.inksystemsinc.com.43897 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:27.074666 IP smtp.inksystemsinc.com.45592 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:27.287149 IP smtp.inksystemsinc.com.55627 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:27.863836 IP smtp.inksystemsinc.com.54775 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:28.064734 IP smtp.inksystemsinc.com.42372 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:29.107981 IP smtp.inksystemsinc.com.38735 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:29.309311 IP smtp.inksystemsinc.com.41803 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:29.885521 IP smtp.inksystemsinc.com.46028 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:30.086696 IP smtp.inksystemsinc.com.52997 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:31.134974 IP smtp.inksystemsinc.com.60018 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:31.336257 IP smtp.inksystemsinc.com.58666 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:31.889111 IP smtp.inksystemsinc.com.34483 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:32.125685 IP smtp.inksystemsinc.com.50513 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:33.160631 IP smtp.inksystemsinc.com.59358 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:33.362719 IP smtp.inksystemsinc.com.33979 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:33.889878 IP smtp.inksystemsinc.com.57796 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:34.127055 IP smtp.inksystemsinc.com.58885 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:35.189193 IP smtp.inksystemsinc.com.50615 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:35.391723 IP smtp.inksystemsinc.com.58513 > deekayen.net.ntp: NTPv4, Client, length 48
12:24:35.916880 IP smtp.inksystemsinc.com.52794 > clock.trit.net.ntp: NTPv4, Client, length 48
12:24:36.151963 IP smtp.inksystemsinc.com.41172 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:24:37.219853 IP smtp.inksystemsinc.com.50053 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:24:37.421983 IP smtp.inksystemsinc.com.54911 > deekayen.net.ntp: NTPv4, Client, length 48
12:26:44.993577 IP smtp.inksystemsinc.com.33387 > clock.trit.net.ntp: NTPv4, Client, length 48
12:26:45.894067 IP smtp.inksystemsinc.com.37791 > 131.107.13.100.ntp: NTPv4, Client, length 48
12:26:47.006712 IP smtp.inksystemsinc.com.43237 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:26:47.459310 IP smtp.inksystemsinc.com.51999 > deekayen.net.ntp: NTPv4, Client, length 48
12:31:04.623651 IP smtp.inksystemsinc.com.60481 > clock.trit.net.ntp: NTPv4, Client, length 48
12:31:05.273877 IP smtp.inksystemsinc.com.47396 > origin.towfowi.net.ntp: NTPv4, Client, length 48
12:31:05.474975 IP smtp.inksystemsinc.com.43965 > deekayen.net.ntp: NTPv4, Client, length 48
12:31:06.622505 IP smtp.inksystemsinc.com.60713 > 131.107.13.100.ntp: NTPv4, Client, length 48


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20150909/5f63b1a8/attachment-0001.html>


More information about the users mailing list