NTP: take into account systemd-timesyncd where present

Thanks for the bug report. This is in progress already, but may not be solved in exactly the way you are suggesting. I'll let Ryan comment on specific implementation as he sees fit.

Note, while timesyncd does have a compiled in value, it can be modified, and cloud-init already knows how to render a systemd-timesyncd configuration file to set the ntp configuration.

# cat /etc/cloud/templates/timesyncd.conf.tmpl
## template:jinja
# cloud-init generated file
# See timesyncd.conf(5) for details.

[Time]
{% if servers or pools -%}
NTP={% for host in servers|list + pools|list %}{{ host }} {% endfor -%}
{% endif -%}

Ntpd and timesyncd never compete, when ntpd (or other time clients) are installed the timesyncd unit will no longer run as it includes a Conditional setting (which looks to be regressed/missing in bionic)

root@x1:/lib/systemd/system/systemd-timesyncd.service.d# cat disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

That said, timesyncd is only utilized on Ubuntu-Core systems using cloud-init.
We are in the process of updating the ntp module to allow users to specify as well
as preferring already installed NTP clients.

https://hackmd.io/s/r1qN6HNbz

Some further looking at the systemd side, Bionic no longer carries the override conf (disable-with-time-daemon.conf) in favor of updating each client's systemd unit to use:

Conflicts=systemd-timesyncd.service

Conflicts will ensure that the target service is stopped if the current unit is started. So, if ntp or chrony unit were to start, it would stop timesyncd.

This is roughly equivalent, however, it does leave timesyncd unit enabled. This means that if something starts systemd-timesyncd.service, it would stop the ntp or chrony service.

There may be additional work on each of the time packages to *disable* timesyncd unit when installed such that it won't start. This may not be possible to prevent users from starting timesyncd manually.

I think cloud-init is the oracle of information of which ntp daemon to use, and which ntp servers to use. Thus on bionic+ cloud-init, when configuring ntp, should also "disable systemd-timesyncd" if some alternative NTP server is to be used.

"if some alternative NTP server is to be used." should read "if some alternative NTP client daemon is to be used." obviously =)

On Mon, Feb 19, 2018 at 9:33 AM, Dimitri John Ledkov <<email address hidden>
> wrote:

> I think cloud-init is the oracle of information of which ntp daemon to
> use, and which ntp servers to use. Thus on bionic+ cloud-init, when
> configuring ntp, should also "disable systemd-timesyncd" if some
> alternative NTP server is to be used.
>

I'm not opposed to having cloud-init do that. But systemd and ntp clients
are
installable outside of cloud images and they should behave consistently
there.
I think a combination of the override which prevents timesyncd from
starting if a client
is present *and* the Conflicts= that's present in Bionic should be in the
packaging.

Such a configuration would prevent timesyncd starting from stopping other
clients.

> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1749722
>
> Title:
> NTP: take into account systemd-timesyncd where present
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1749722/+subscriptions
>

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=c6dff581

This bug is believed to be fixed in cloud-init in version 18.3. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

please reopen if this is still an issue

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3119