Comment 5 for bug 1706818

@Robie - IIRC Paul wants to use it as "remote ntp check" which actually should be done via sntp but that binary was unavailable until artful and the fix doesn't fit an SRU (bug 1604010).

@Josh - just a day after your report the SRU completed that took out the old locking and the silly unconditional restart from the ifup hooks. I'd hope things should be much better for you now - could you please verify if that is true for your scenario as well?
If not we have to search where the remaining issue comes from as the new behavior should have ntp preferred to ntpdate and ntpdate being the one rejected as ntp already has the port used.
If there is a window e.g. due to the many interfaces that you described - that inverts that with ntpdate blocking ntp still that would have to be fixed.