Comment 7 for bug 1706818

- Taking a Xenial and a Artful VM
- Installing ntp
- Check status of ntp
  - running fine on both systems
- Reboot the VM
- Check status of ntp
  - still ntp service ok on both systems
- install ntpdate
- Check status of ntp
  - still ntp service ok on both systems
- reboot
- Check status of ntp
  - failed for blocked known address being busy on both
- reboot (to check reproducibility)
- Check status of ntp
  - failed for blocked known address being busy on both
- Adding two extra devices in libvirt and configuring it on the guest
- restart
- Check status of ntp
  - failed for blocked known address being busy on both (likely even at a higher "risk")

ntp init mechanims:
Xenial: /etc/init.d/ntp locks LOCKFILE=/var/lock/ntpdate
Artful: /usr/lib/ntp/ntp-systemd-wrapper locks nothing at all

This races against the following hook (in both releases):
/etc/network/if-up.d/ntpdate which locks /run/lock/ntpdate

Seems reproducible enough to me, actually much better reproducible than in the past.
I checked and our recent cleanup of the mess around debian/ntpdate.if-up fixed a lot of things.
Among other it removed an accidential restart of ntp which kind of hid this issue here (no regression-update, just an issue existing before now more likely to be hit).

But now with things no more that racy the fix is easy and much better testable.