Re: [chrony-dev] chronyd feature request: aggressive mode
On Wed, Dec 11, 2019 at 03:57:50PM +0700, Gerriet M. Denkmann wrote: > chronyd does a good job of keeping the time in sync without big changes in > the drift (freuquency). > > But there are a few situations, where an “aggressive mode” (i.e. drastically > increasing the frequency) would be more appropriate: > > (1) at start > (2) when there is a big time-error (ntp-time - cpu-time) (e.g. > 2 sec) > (3) (at least on macOS) when the computer wakes up from sleep. The speed of the correction is controlled by the "corrtimeratio" directive. The default is quite aggressive. I suspect you may be limited by the maximum slew rate. If you see a "system time" offset value in the tracking report smaller than one second and decreasing by about 500 microseconds per second, chronyd is at the limit. The only way to correct the clock faster would be a step (makestep directive). > (3) On macOS there is usually a time-error of -1 … +2 seconds upon wake up. > (rarely more than 2 sec) (this is only true with rtcsync working). > The problem here: when chronyd thinks that all is stable, the next check with > ntp might by delayed by up to 17 min (sometime up to 53 min). > And for usual errors < 2 sec, case (2) does not apply. This results in almost > an hour (depending of course on the wake-up error) until the time is correct > again. > Here I would like to see an “aggressive mode” until the time-error is down to > a few msec. So, here agressive means a shorter polling interval, so the correction will start sooner? chronyd doesn't know when the system is suspended/resumed, but there should be a system-specific way to run "chronyc burst 4/4" when that happens. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] chronyd feature request: aggressive mode
chronyd does a good job of keeping the time in sync without big changes in the drift (freuquency). But there are a few situations, where an “aggressive mode” (i.e. drastically increasing the frequency) would be more appropriate: (1) at start (2) when there is a big time-error (ntp-time - cpu-time) (e.g. > 2 sec) (3) (at least on macOS) when the computer wakes up from sleep. (1) my computer usually runs for months without shut-down or reboot. So maybe chronyd already does the right thing in this situation. (2) I have seen rather big frequencies (up to 20-fold of normal drift resulting from a time-error of 45 sec). So this case also seems to be handled ok. (3) On macOS there is usually a time-error of -1 … +2 seconds upon wake up. (rarely more than 2 sec) (this is only true with rtcsync working). The problem here: when chronyd thinks that all is stable, the next check with ntp might by delayed by up to 17 min (sometime up to 53 min). And for usual errors < 2 sec, case (2) does not apply. This results in almost an hour (depending of course on the wake-up error) until the time is correct again. Here I would like to see an “aggressive mode” until the time-error is down to a few msec. Would this be possible? Or are there reasons, why this is *not* a good idea? Gerriet. -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 5:42 PM Miroslav Lichvar
wrote:
> On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> > That means the first switch_interrupts call from RTC_Initialise ->
> > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> > trigger the issue at initialization phase.
> > Later on on RTC_TimeInit -> switch_interrupts argument on_off=1 and the
> > issue occurs.
> > Turns out our "problematic" RTCs only trigger the issue on on_off=1.
>
> Interesting. When I added that code I checked the kernel source code
> and it looked like enabling and disabling the interrupt should both
> return the same error.
>
> What RTC driver is used on the machine?
>
I think I mentioned this before, the two failing ones are:
PPC64
# dmesg | grep -i rtc
[0.241872] rtc-generic rtc-generic: registered as rtc0
[0.270221] rtc-generic rtc-generic: setting system clock to
2019-12-06T08:18:19 UTC (1575620299)
ARM64
# dmesg | grep -i rtc
[0.876198] rtc-efi rtc-efi: registered as rtc0
[1.046869] rtc-efi rtc-efi: setting system clock to 2019-12-10T11:44:59
UTC (1575978299)
> >/* Make sure the RTC supports interrupts */
> > - if (!switch_interrupts(0)) {
> > + if (!switch_interrupts(1) || switch_interrupts(0)) {
> > close(fd);
> > return 0;
> >}
>
> I'd prefer this approach, but I think there is a missing "!" before
> the second call of switch_interrupts().
>
Agreed
With that it behaves like the following (hang fixed):
# ./run -d 101-rtc
101-rtc Testing real-time clock:
non-default settings:
extra_chronyd_directives=rtcfile
/home/ubuntu/chrony/test/system/tmp/rtcfile
extra_chronyd_options=-s
minimal_config=1
starting chronyd OK
stopping chronyd OK
checking message "\(clock off from RTC\|RTC time before last\)" BAD
FAIL
SUMMARY:
TOTAL 1
PASSED 0
FAILED 1(101-rtc)
SKIPPED 0 ()
root@bos01-ppc64-chrony-adt-issue:/home/ubuntu/chrony/test/system# tail -n
20 tmp/*
==> tmp/chronyd.conf <==
pidfile /home/ubuntu/chrony/test/system/tmp/chronyd.pid
bindcmdaddress /home/ubuntu/chrony/test/system/tmp/chronyd.sock
port 17575
cmdport 14432
rtcfile /home/ubuntu/chrony/test/system/tmp/rtcfile
==> tmp/chronyd.log <==
2019-12-12T07:20:35Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-12T07:20:35Z Disabled control of system clock
2019-12-12T07:20:35Z Could not enable RTC interrupt : Invalid argument
2019-12-12T07:20:35Z chronyd exiting
==> tmp/chronyd.out <==
==> tmp/driftfile <==
0.0 1
==> tmp/keys <==
1 MD5 abcdefghijklmnopq
==> tmp/rtcfile <==
1 1576135235 0.0 0.0
==> tmp/tempcomp <==
0.0
> I've understood that you wanted it to hard-fail and bail out of -s was set
> > but RTC init failed right?
>
> No, it should continue to run (using other time sources as configured).
>
Thanks for explaining that - that seems correct for the general case
(outside of the tests).
But that still means the test would flag "chrony broken" for test 101-rtc
in places where we know the reason are RTC clocks not supporting an option.
I'd suggest to also add the initial patch I had that skips the test in
those cases.
I'll send a v2 (for internationalization) and add a commit for
the switch_interrupts 0+1 as discussed above
--
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble? Email listmas...@chrony.tuxfamily.org.
>
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
[chrony-dev] [PATCH v2 2/2] rtc: extend check for RTCs that don't support interrupts
Several RTCs would only expose the broken behavior on enabling
interrupts. Therefore the check has to probe switch_interrupts(1) as
well.
Clocks known to expose that behavior include, but are not limited to:
PPC64# dmesg | grep -i rtc
[ 0.241872] rtc-generic rtc-generic: registered as rtc0
[ 0.270221] rtc-generic rtc-generic: setting system clock to ...
ARM64# dmesg | grep -i rtc
[ 0.876198] rtc-efi rtc-efi: registered as rtc0
[ 1.046869] rtc-efi rtc-efi: setting system clock to ...
Signed-off-by: Christian Ehrhardt
---
rtc_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtc_linux.c b/rtc_linux.c
index aee768f..a44a912 100644
--- a/rtc_linux.c
+++ b/rtc_linux.c
@@ -516,7 +516,7 @@ RTC_Linux_Initialise(void)
}
/* Make sure the RTC supports interrupts */
- if (!switch_interrupts(0)) {
+ if (!switch_interrupts(1) || !switch_interrupts(0)) {
close(fd);
return 0;
}
--
2.24.0
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] [PATCH v2 1/2] test: check if RTC is RTC_UIE_ON capable
The test might run on different platforms. If the platform happens to have a RTC that does exist but unable to have RTC_UIE_ON set the test will fall into an infinite hang. Exampls of bad clocks are: - ppc64el: rtc-generic - arm64: rtc-efi To avoid that check the capability via `hwclock` before the test and skip if it is unable to use it. Output generally looks like: ioctl(4, RTC_UIE_ON, 0): Invalid argument But for internationalization only compare the left part of it. In the good case this line won't show up at all. Signed-off-by: Christian Ehrhardt --- test/system/101-rtc | 1 + 1 file changed, 1 insertion(+) diff --git a/test/system/101-rtc b/test/system/101-rtc index fa9a70d..4ddca1e 100755 --- a/test/system/101-rtc +++ b/test/system/101-rtc @@ -4,6 +4,7 @@ check_chronyd_features RTC || test_skip "RTC support disabled" [ -c "/dev/rtc" ] || test_skip "missing /dev/rtc" +hwclock -r --test | grep -q '^ioctl(.*RTC_UIE_ON, 0):' && test_skip "RTC not RTC_UIE_ON capable" test_start "real-time clock" -- 2.24.0 -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] [PATCH v2 0/2] fix RTC issues on some platforms
Here an update to my patches on the topic. The changes of Miroslav already helped a lot, thanks! Out of our discussion and debugging here an updated set of patches that would fix behavior with the clocks that I encountered and skip tests to not false-positive flag chrony (while instead the RTC is what is broken). Updates in v2: - reduce the check to work if the error messages are internationalized - add check to cover RTCs only misbehaving on enabling IRQs Christian Ehrhardt (2): test: check if RTC is RTC_UIE_ON capable rtc: extend check for RTCs that don't support interrupts rtc_linux.c | 2 +- test/system/101-rtc | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.24.0 -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On 2019-12-11T16:13+0100, Christian Ehrhardt wrote: On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar wrote: On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote: > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar > > I'm sorry for changing my mind, but I now think this case should be > > handled gracefully in chronyd and not avoided in the test. According > > to the man page, the -s option is supposed to work even with no RTC or > > broken RTCs. A hang or fatal error with the -s option may break > > the user's expectation. > > > > Do you agree? > > > > Yes, but I think the changes are not mutually exclusive and should both be > added. > > -s needs the change you suggested to make the fail fatal. As I tried to explain in the later post, I think chronyd -s should not fail if the RTC doesn't support interrupts, as the documentation implies chronyd can work with "broken" RTCs and we shouldn't expect the users to test it before configuring chronyd. > Otherwise users will not realize that they don't get what they ordered. There will still be the error message in the log. Can you please try the test again with the latest code? I tested with the current head being commit f5eb7daf "rtc: disable interrupts in finalization" With that the test finally worked on the two affected platforms that I had: ./run -d 103-refclock 103-refclock Testing reference clocks: non-default settings: extra_chronyd_directives= refclock SOCK /home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100 starting chronyd OK waiting for synchronization OK stopping chronyd OK checking chronyd messages OK checking chronyd filesOK PASS SUMMARY: TOTAL 1 PASSED 1 FAILED 0() SKIPPED 0 () What about the 101-rtc test, Christian? ;-) signature.asc Description: PGP signature
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > > I'm sorry for changing my mind, but I now think this case should be
> > > handled gracefully in chronyd and not avoided in the test. According
> > > to the man page, the -s option is supposed to work even with no RTC or
> > > broken RTCs. A hang or fatal error with the -s option may break
> > > the user's expectation.
> > >
> > > Do you agree?
> > >
> >
> > Yes, but I think the changes are not mutually exclusive and should both
> be
> > added.
> >
> > -s needs the change you suggested to make the fail fatal.
>
> As I tried to explain in the later post, I think chronyd -s should not
> fail if the RTC doesn't support interrupts, as the documentation
> implies chronyd can work with "broken" RTCs and we shouldn't expect
> the users to test it before configuring chronyd.
>
> > Otherwise users will not realize that they don't get what they ordered.
>
> There will still be the error message in the log.
>
> Can you please try the test again with the latest code?
>
I tested with the current head being commit f5eb7daf "rtc: disable
interrupts in finalization"
With that the test finally worked on the two affected platforms that I had:
./run -d 103-refclock
103-refclock Testing reference clocks:
non-default settings:
extra_chronyd_directives= refclock SOCK
/home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100
starting chronyd OK
waiting for synchronization OK
stopping chronyd OK
checking chronyd messages OK
checking chronyd filesOK
PASS
SUMMARY:
TOTAL 1
PASSED 1
FAILED 0()
SKIPPED 0 ()
But when run in debug mode it still looks the same:
$ ./chronyd -d -s -f /root/chronyd.conf
019-12-11T14:37:35Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-11T14:37:36Z System time set from RTC
2019-12-11T14:37:36Z Initial frequency -13.014 ppm
2019-12-11T14:37:36Z Could not enable RTC interrupt : Invalid argument
I'd have expected a fatal exit in these cases now - is that right?
>From reading the (new) code I'd expect RTC_Linux_Initialise to now detect
the problem and return 0 from this new section:
+ /* Make sure the RTC supports interrupts */
+ if (!switch_interrupts(0)) {
+close(fd);
+return 0;
+ }
But what I see happening is this:
gdb) b RTC_Finalise
Breakpoint 1 at 0x11bc8: file rtc.c, line 162.
(gdb) b RTC_Initialise
Breakpoint 2 at 0x119b8: file rtc.c, line 115.
(gdb) b RTC_Linux_Initialise
Breakpoint 3 at 0x373e8: file rtc_linux.c, line 509.
(gdb) b switch_interrupts
Breakpoint 4 at 0x36d28: switch_interrupts. (2 locations)
(gdb) run -d -s -f /root/chronyd.conf
Starting program: /home/ubuntu/chrony/chronyd -d -s -f /root/chronyd.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/powerpc64le-linux-gnu/libthread_db.so.1".
2019-12-11T14:43:05Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2019-12-11T14:43:05Z Wrong owner of /var/run/chrony (UID != 0)
2019-12-11T14:43:05Z Disabled command socket /var/run/chrony/chronyd.sock
Breakpoint 2, 0x0001000119b8 in RTC_Initialise (initial_set=1) at
rtc.c:115
115 {
(gdb) n
125 if (initial_set) {
(gdb)
126 driftfile_time = get_driftfile_time();
(gdb)
128 if (driver.time_pre_init &&
driver.time_pre_init(driftfile_time)) {
(gdb)
129 driver_preinit_ok = 1;
(gdb)
137 driver_initialised = 0;
(gdb)
141 file_name = CNF_GetRtcFile();
(gdb)
143 if (file_name) {
(gdb)
144 if (CNF_GetRtcSync()) {
(gdb)
149 if ((driver.init)()) {
(gdb)
Breakpoint 3, 0x0001000373e8 in RTC_Linux_Initialise () at
rtc_linux.c:509
509 {
(gdb)
511 fd = open(CNF_GetRtcDevice(), O_RDWR);
(gdb)
512 if (fd < 0) {
(gdb)
519 if (!switch_interrupts(0)) {
(gdb)
Breakpoint 4, 0x000100036d28 in switch_interrupts (on_off=0) at
rtc_linux.c:489
489 {
(gdb)
490 if (ioctl(fd, on_off ? RTC_UIE_ON : RTC_UIE_OFF, 0) < 0) {
(gdb)
RTC_Linux_Initialise () at rtc_linux.c:525
525 UTI_FdSetCloexec(fd);
(gdb)
527 rtc_sec = MallocArray(time_t, MAX_SAMPLES);
(gdb)
528 rtc_trim = MallocArray(double, MAX_SAMPLES);
(gdb)
529 system_times = MallocArray(struct timespec, MAX_SAMPLES);
(gdb)
532 setup_config();
(gdb)
535 coefs_file_name = CNF_GetRtcFile();
(gdb)
537 n_samples = 0;
(gdb)
538 n_samples_since_regression = 0;
(gdb)
539 n_runs = 0;
(gdb)
540 coefs_valid = 0;
(gdb)
547 SCH_AddFileHandler(fd, SCH_FILE_INPUT,
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> That means the first switch_interrupts call from RTC_Initialise ->
> RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> trigger the issue at initialization phase.
> Later on on RTC_TimeInit -> switch_interrupts argument on_off=1 and the
> issue occurs.
> Turns out our "problematic" RTCs only trigger the issue on on_off=1.
Interesting. When I added that code I checked the kernel source code
and it looked like enabling and disabling the interrupt should both
return the same error.
What RTC driver is used on the machine?
>/* Make sure the RTC supports interrupts */
> - if (!switch_interrupts(0)) {
> + if (!switch_interrupts(1) || switch_interrupts(0)) {
> close(fd);
> return 0;
>}
I'd prefer this approach, but I think there is a missing "!" before
the second call of switch_interrupts().
> I've understood that you wanted it to hard-fail and bail out of -s was set
> but RTC init failed right?
No, it should continue to run (using other time sources as configured).
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Re: [PATCH] test: check if RTC is RTC_UIE_ON capable
On Wed, Dec 11, 2019 at 4:24 PM Vincent Blut wrote: > On 2019-12-11T16:13+0100, Christian Ehrhardt wrote: > >On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar > >wrote: > > > >> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote: > >> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar > > >> > > I'm sorry for changing my mind, but I now think this case should be > >> > > handled gracefully in chronyd and not avoided in the test. According > >> > > to the man page, the -s option is supposed to work even with no RTC > or > >> > > broken RTCs. A hang or fatal error with the -s option may break > >> > > the user's expectation. > >> > > > >> > > Do you agree? > >> > > > >> > > >> > Yes, but I think the changes are not mutually exclusive and should > both > >> be > >> > added. > >> > > >> > -s needs the change you suggested to make the fail fatal. > >> > >> As I tried to explain in the later post, I think chronyd -s should not > >> fail if the RTC doesn't support interrupts, as the documentation > >> implies chronyd can work with "broken" RTCs and we shouldn't expect > >> the users to test it before configuring chronyd. > >> > >> > Otherwise users will not realize that they don't get what they > ordered. > >> > >> There will still be the error message in the log. > >> > >> Can you please try the test again with the latest code? > >> > > > >I tested with the current head being commit f5eb7daf "rtc: disable > >interrupts in finalization" > > > >With that the test finally worked on the two affected platforms that I > had: > >./run -d 103-refclock > >103-refclock Testing reference clocks: > > non-default settings: > >extra_chronyd_directives= refclock SOCK > >/home/ubuntu/chrony/test/system/tmp/refclock.sock refclock SHM 100 > > starting chronyd OK > > waiting for synchronization OK > > stopping chronyd OK > > checking chronyd messages OK > > checking chronyd filesOK > >PASS > > > > > >SUMMARY: > > TOTAL 1 > > PASSED 1 > > FAILED 0() > > SKIPPED 0 () > > What about the 101-rtc test, Christian? ;-) > Hehe, silly typo while tabbing commands - yeah you are right. 101 still fails the same way, and thereby matching the -d check. I have rebuilt and rerun the test twice, but above issue remains. arm64 and ppc64el behave the same way on this. Fortunately all the debugging info of above still is correct and might still help to get closer to a final fix. BTW - on debugging you have to be careful, the following checking message "\(clock off from RTC\|RTC time before last\)" BAD means there likely is a stale chrony process test left from a former test. BTW after the failing 101-rtc test the files in tmp say: # head -n 20 tmp/* ==> tmp/chronyd.conf <== pidfile /home/ubuntu/chrony-ubuntu-git/test/system/tmp/chronyd.pid bindcmdaddress /home/ubuntu/chrony-ubuntu-git/test/system/tmp/chronyd.sock port 16097 cmdport 13626 rtcfile /home/ubuntu/chrony-ubuntu-git/test/system/tmp/rtcfile ==> tmp/chronyd.log <== 2019-12-11T15:53:06Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 2019-12-11T15:53:06Z Disabled control of system clock 2019-12-11T15:53:06Z Could not enable RTC interrupt : Invalid argument 2019-12-11T15:54:37Z chronyd exiting Note: ^^ this exit is me with CTRL+C after a while ==> tmp/chronyd.out <== ==> tmp/driftfile <== 0.0 1 ==> tmp/keys <== 1 MD5 abcdefghijklmnopq ==> tmp/rtcfile <== 1 1576079586 0.0 0.0 ==> tmp/tempcomp <== 0.0 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
[chrony-dev] chronyc tab completion, libedit 20191025-3.1 regression
Hi Devs, Just a quick note, related to chronyc tab completion ... libedit 20191025-3.1 has a regression and does not add a space character after a match ... sounds minor but actually causes problems. libedit 20191211-3.1 fixes the problem. https://thrysoee.dk/editline/ Thanks to Christos Zoulas for the fix and Jess Thrysoee for generating a new Linux tarball, in a timely manner. The sqlite3 CLI tool had the same issue with 20191025-3.1, actually any application that defines 'rl_attempted_completion_function' won't work properly with 20191025-3.1 . Lonnie -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
