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@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
----------------------------------------------------------------------
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx -
- 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@xxxxxxxxxxxxxxxxxxxxxxx
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
