Bug 1126590

Summary:	chronyd fails to connect after reboot but is ok after service restart
Product:	[Fedora] Fedora	Reporter:	John Florian <john>
Component:	chrony	Assignee:	Miroslav Lichvar <mlichvar>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	mlichvar
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-05 08:36:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Florian 2014-08-04 20:52:27 UTC

Description of problem:
Since upgrading chrony we've noticed that the daemon cannot connect to its upstream server after rebooting.  If we restart the service it will be fine however.

Version-Release number of selected component (if applicable):
chrony-1.30-1.fc20.x86_64 (upgraded from 1.29-1)

How reproducible:
always

Steps to Reproduce:
1. install 1.30
2. reboot
3. run "chronyc source" and note the "?" in the S(tatus) column.
4. systemctl status chrony.service shows "Could not connect NTP socket to a.b.c.d:123 : Network is unreachable"
5. systemctl restart chrony.service
6. repeat steps 3 and 4; things should look fine now
7. repeat steps 2 through 6 and notice that it's repeatable

Additional info:
If we "yum downgrade chrony" (back to 1.29-1) the problem goes away.  If we upgrade again, it comes back.

Comment 1 Miroslav Lichvar 2014-08-05 08:36:10 UTC

Thanks for the report. It seems to be similar to the bug #1124059. The difference is that here the connecting fails immediately on start (possibly because the servers are specified in chrony.conf by IP addresses instead of names) and in the other bug it fails after offline+online commands issued on system suspend/resume.

*** This bug has been marked as a duplicate of bug 1124059 ***