Bug 1660361 - ntpdate fails to start on system having bond interface.
Summary: ntpdate fails to start on system having bond interface.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ntp
Version: 7.6
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-18 08:27 UTC by Rupesh Patel
Modified: 2019-03-21 15:25 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-03-21 15:24:14 UTC
Target Upstream Version:

Attachments (Terms of Use)

Comment 5 Lukáš Nykrýn 2019-03-04 10:10:07 UTC
I am not sure we can do anything clever here when the network.service ends, the network is configured and up. The fact that they are not able to get to the NTP servicer is related to the infrastructure below and we can't just add "wait until you ping the server".

Comment 6 Lukáš Nykrýn 2019-03-04 10:16:12 UTC
The easiest workaround here would be to create a timer unit, that will start the service a bit later. But anyway, there is no bug in systemd, it starts the services as expected. Let's reassign it to ntpdate to get Mirek's opinion, but I am afraid that this should be closed as "can't fix"

Comment 7 Miroslav Lichvar 2019-03-04 16:15:55 UTC
I suspect ntpdate is not the only service that has an ordering dependency on network and breaks if it started before the network is working.

I guess the right place to fix this would be in the network init script. It should wait for the bond interface to be fully "up" before exiting, similarly to how it waits for DHCP. I'm not sure if there is a state that could be monitored for this purpose.

Comment 8 Lukáš Nykrýn 2019-03-05 08:46:41 UTC
Unfortunately, there is no such mechanism. So as mentioned in comment 6, this is really a can't fix.

Comment 9 Miroslav Lichvar 2019-03-21 14:29:36 UTC
We should consider partially reverting changes that were made for bug #1466947 (adding dependency on network-online.target).

Before that fix, ntpdate was executed several times in an exponentially increasing interval if it was not able to set the clock.

Comment 10 Rupesh Patel 2019-03-21 15:24:14 UTC
We can close this bz as another customer who reported a similar incident isn't using ntpdate anymore. 
I could see other services failing at the time of boot e.g rsyslog because of bond took time to come up.
I will open a separate bug if the customer insists to fix it.

Note You need to log in before you can comment on or make changes to this bug.