chrony: better config requested

[Artoria2e5]

Bug description

We currently have

aosc-os-abbs/app-admin/chrony/autobuild/beyond

Line 4 in 5e94a4b

echo -e "\n# Enable kernel RTC sync\nrtcsync" >> "$PKGDIR"/etc/chrony.conf

This degrades precision because this turns off RTC drift rate tracking.

Steps to reproduce

• run chronyd somehow
• run chronyc
• type "rtcdata"

Update channel(s)

stable

Package and version

Same as last time

Recommended fix:

Instead of rtcsync, write rtcfile /var/lib/chrony/rtc\nrtcautotrim 1.

[Artoria2e5]

Huuuuhhhh you know, there's actually a lot of defaults that aren't making sense right now. Like

• we don't even have a server to use
• adjtime somehow has no compiled-in default
• this rtc stuff
• hwtimestamp not on by default

[KexyBiscuit]

Using official chrony.conf.example3 now, closing as fixed.

[Artoria2e5]

You are still using rtcsync!

[Artoria2e5]

Alright. Maybe trying to track the RTC is silly on a random computer that we don't know is going to be off for long. But I still have qualms (more like nitpicks) with how it's done:

• We changed an example. We could have just made a copy and change that copy.
• Patches are hard to edit. A lot of these can be done with just sed, like a6eb86a __chrony_uncomment function.
• The patch’s title is deceptive. In that same commit, I kept the service patch and had to change the file name.

I think we can also look at what others are doing. For example, here's what RH distros do to generate the conf (taken from their spec file):

# use example chrony.conf as the default config with some modifications:
# - use our vendor zone (2.*pool.ntp.org names include IPv6 addresses)
# - enable leapseclist to get TAI-UTC offset and leap seconds
# - use NTP servers from DHCP
sed -e 's|^\(pool \)\(pool.ntp.org\)|\12.%{vendorzone}\2|' \
    -e 's|#\(leapseclist\)|\1|' \
    -e 's|^pool.*pool.ntp.org.*|&\n\n# Use NTP servers from DHCP.\nsourcedir /run/chrony-dhcp|' \
        < examples/chrony.conf.example2 > chrony.conf

Since chrony is an RH project, their defaults are probably sensible. (Gotta say this un-commenting is much more clever than my sed slop.)

[KexyBiscuit]

• We changed an example. We could have just made a copy and change that copy.

I intended to change the example, so once the related sections of the example have been updated, the patch will fail to be applied, raising maintainer's attention to update it. New default values are often good to have.

• Patches are hard to edit. A lot of these can be done with just sed, like a6eb86a __chrony_uncomment function.

That's where @AOSC-Tracking comes in. VCS first, patches auto-generated.

I understand that patching the upstream default might not be the best approach, but at least I'm not alone... https://salsa.debian.org/debian/shadow/-/blob/ccaa7ea01ec2fcbfc99bc58306eb717e477466ec/debian/patches/debian/Adapt-login.defs-for-Debian.patch

Let's focus on what config to change for now.

• What's the upside of tracking accuracy of the RTC with rtcfile directive?
• AOSC OS currently doesn't have /etc/adjtime/ file shipped. Leave hwclockfile directive to its default seems OK to me.
• What's the upside of enabling hardware timestamping on all interfaces instead of using software timestamping?

[Artoria2e5]

1. Turning on rtcfile is helpful for systems that are powered-off for months at a time, and specifically those without any other OS to touch an RTC. I don't think this is useful in the general case any longer, so nope.
2. Seems okay to me too. Again, finer-grained RTC thing is, uh, yeah whatever. I recommend just rtcsync
3. It enables it only if it's available. And trust me you want to enable it if it's available: you get much less jitter from CPU utilization swings, because the NIC is doing the work itself. It's miraculous: https://chrony-project.org/examples.html

---

My recommendation is we fork the example2, and apply

leapseclist 1
pool 2.aoscos.pool.ntp.org
hwtimestamp *

(Basically what Fedora does, plus hwtimestamp.)

The 2. pool is special, in that only 2. returns IPv6 addresses. The NTP pool started experimenting with v6 in ~2017 with 2. but never got to expanding it to all prefixes. It's fine for us, because pool tells chrony to get multiple anyways.

[KexyBiscuit]

1. Turning on rtcfile is helpful for systems that are powered-off for months at a time, and specifically those without any other OS to touch an RTC. I don't think this is useful in the general case any longer, so nope.
2. Seems okay to me too. Again, finer-grained RTC thing is, uh, yeah whatever. I recommend just rtcsync
3. It enables it only if it's available. And trust me you want to enable it if it's available: you get much less jitter from CPU utilization swings, because the NIC is doing the work itself. It's miraculous: https://chrony-project.org/examples.html

My recommendation is we fork the example2, and apply

leapseclist 1
pool 2.aoscos.pool.ntp.org
hwtimestamp *

(Basically what Fedora does, plus hwtimestamp.)

The 2. pool is special, in that only 2. returns IPv6 addresses. The NTP pool started experimenting with v6 in ~2017 with 2. but never got to expanding it to all prefixes. It's fine for us, because pool tells chrony to get multiple anyways.

{0,1,2,3}.aoscos.pool.ntp.org was not setup for us, for unknown reason.