On 2019-12-11T16:13+0100, Christian Ehrhardt wrote:
>On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx>
>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 <mlichvar@xxxxxxxxxx>
>> > > 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 files OK
>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/*