NTP: take into account systemd-timesyncd where present

Bug #1749722 reported by Graham Leggett on 2018-02-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ryan Harper
systemd (Ubuntu)

Bug Description

Currently, the NTP module configures ntpd during cloud-init install by installing and configuring ntpd.

ntpd competes with systemd-timesyncd on systemd distros like Ubuntu Xenial.

Ideally the NTP module should configure systemd-timesyncd where present, falling back to ntpd where not present.

This stops two separate daemons (ntpd and systemd-timesyncd) competing with each other to set the time, where systemd-timesyncd (on Ubuntu at least) has an internal hardcoded compiled in timeserver to fall back on if no timeserver is configured (which is bad, but what can you do).

The competing timeserver behaviour is invisible when the machine can see the net, but logs this error constantly when the machine cannot see the net:

systemd-timesyncd[527]: Timed out waiting for reply from (ntp.ubuntu.com).

Related branches

David Britton (davidpbritton) wrote :

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.

Changed in cloud-init:
assignee: nobody → Ryan Harper (raharper)
status: New → In Progress
importance: Undecided → Medium
Ryan Harper (raharper) wrote :

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.

{% 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
# don't run timesyncd if we have another NTP daemon installed

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.


Ryan Harper (raharper) wrote :

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 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.

Dimitri John Ledkov (xnox) 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.

Dimitri John Ledkov (xnox) wrote :

"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
installable outside of cloud images and they should behave consistently
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

Such a configuration would prevent timesyncd starting from stopping other

> --
> 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

Scott Moser (smoser) wrote :

An upstream commit landed for this bug.

To view that commit see the following URL:

Changed in cloud-init:
status: In Progress → Fix Committed

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.

Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers