Arch Linux

So AFAICT this entirely commented-out file which has a "syntax error" is erroneously? doubling the "iburst" parameter.

Now bear with me because I'm not a chrony user, but I uncommented those lines and this worked entirely properly as far as I can tell

2018-08-26T22:30:58Z chronyd version 3.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2018-08-26T22:30:58Z Frequency -2.003 +/- 15.104 ppm read from /var/lib/chrony/drift
2018-08-26T22:31:06Z Selected source 193.169.139.87
2018-08-26T22:31:07Z Selected source 2600:3c03::f03c:91ff:fe08:894c
2018-08-26T22:32:23Z chronyd exiting

I'd think if there were a syntax error it would complain...

Some other points:

 FS#59806  you're trying to change the default timeserver again, except in chrony's case it's all not-default because this is commented out. Not sure why this matters given that our modifications merely list the available servers in numeric order. They don't set preferences upstream, we don't set preferences downstream, and users still have to uncomment the one they want regardless.

/etc/adjtime should override rtconutc regardless of whether it is set or not, but specifying it would *I assume* cause chrony to default to utc in cases where the adjtime file does not exist. I don't see why that would be a bad thing.

What other distros do is irrelevant, you should try arguing why it makes sense for *us*.
And IMHO simpler is worse, the purpose of this example file is to document the options. It's not like you cannot use one of the other example files instead, which we ship...

I don't see why it is so important to set by default, the commented-out setting leapsectz in an almost entirely commented-out example file. You're missing a *rationale* as for why this whole bug report change should happen.

Thanks for your feedback.

Regarding the sed, error was not the right word. The mistake is that it is doubling the iburst and changes pool.ntp.org where it is used as a name and HTTP address.

>You're missing a *rationale* as for why this whole bug report change should happen.
Currently, Arch is shipping a configuration with the following options uncommented:
driftfile /var/lib/chrony/drift
rtconutc
rtcsync

The PKGBUILD copies example 3 which has driftfile already uncommented, uncomments rtconutc, and then appends instead of uncommenting the existing rtcsync option.

The problem is that these options serve no purpose on their own. If a user just installs and enables chronyd, then time does not sync. A user needs to edit the configuration correctly before synchronization will happen. If Arch is going to ship a modified configuration it should set options that are agreeable and useful. To address your point on rtconutc: both chrony and timedatectl take no /etc/adjtime file to mean UTC. There is just no need to set rtconutc at all. This change fixes all the mentioned issues.

Attached is a revised PKGBUILD that as per your comments uses example 3 instead of example 2. It has the following options uncommented:
pool 2.arch.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
leapsectz right/UTC
makestep 1.0 3
rtcsync

Note that these are the same uncommented options as example 1 plus leapsectz. I suspect that leapsectz is not included in example 1 upstream because it requires that the operation system has an up to date tzdata for it to work properly. It is useful because it allows the system to determine TAI-UTC offset and when will the next leap second occur without requiring a time server to announce it.

And yes, this uses 2.arch.pool.ntp.org but it is a different situation here compared to systemd-timesyncd because when used as a pool any other zone would fail completely on an IPv6 only connection. It is more important to list the zones in an order that affects usability than numerical order.

The configuration that I am suggesting is an improvement over the existing one because it provides time synchronization that will work for the vast majority of situations by default. If a user has more specific requirements and has a system that works with the more system dependent options they can simply uncomment them.

> when used as a pool any other zone would fail completely on an IPv6 only connection

Interesting, and thanks for clarifying.

Given this new explanation I suppose I see where you're coming from, so let's see what the package maintainer thinks.

Attached is a PKGBUILD updated for chrony 3.4-1

this slipped through my radar, let me take a look and give feedback

Any progress? The latest PKGBUILD that I posted can be applied to the repository without any changes. Is there anything that I can do to help get this reviewed and merged?

sounds reasonable to me, i have added the changes.