[oe] systemd failing in master with Assertion clock_gettime(map_clock_id(clock_id), &ts) failed

[Alex Kiernan]

On Fri, Jan 24, 2020 at 12:22 AM Khem Raj <raj.khem at gmail.com> wrote:
>
> On 1/23/20 4:13 PM, Alex Kiernan wrote:
> > On Thu, Jan 23, 2020 at 10:09 AM Andreas Müller <schnitzeltony at gmail.com> wrote:
> >>
> >> On Thu, Jan 23, 2020 at 10:43 AM Alex Kiernan <alex.kiernan at gmail.com> wrote:
> >>>
> >>> On the offchance someone's tripped over this already/has pointers:
> >>>
> >>> Around the time python2 dropped out, I'm now seeing boot failures with:
> >>>
> >>> [  612.151548] systemd-journald[543]: Assertion
> >>> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> >>> src/basic/time-util.c:55, function now(). Aborting.
> >>>
> >>> I suspect it's unrelated to py2, but that's delayed me getting to the problem.
> >>>
> >>> The board I'm targetting is AM335x based, but without an RTC (which I
> >>> suspect may be relevant).
> >>>
> >>> Anyone seen anything similar?
> >>>
> >>> --
> >>> Alex Kiernan
> >> Hi Alex,
> >>
> >> Have not seen that one yet. Will look for it once I can build images
> >> in current environment (python2/Qt5.14 broke loads for me). What I
> >> have seen were problems with timedatectl <-> ntp. Changing from local
> >> time to ntp-sync did not work: Time remained un-synced on recent
> >> images. Machine was Raspi so no RTC either.
> >>
> >> Don't know if this is related to your finding...
> >>
> >
> > Looks like it's related to the glibc bump - reverting that changeset
> > gets it booting again. I struggle to figure out which of the myriad
> > wrappers are actually being used from inspecting the glibc source, but
> > if it's the one I think it is, there's clearly
> > clock_gettime/clock_gettime64 changes there which I doubt my kernel
> > has (we're currently using the TI 4.19.y kernel).
>
> Is it possible for you to try 5.x for tests ?

That's where I went first, though I need to bring up the newer TI 5.4
branch first (which has its own problems as there's some patch which
was in the 4.9.y hsmmc driver which isn't in the latest which causes
random timeouts on some of our board samples).

> I know there were 64bit
> time_t related errors I saw with 4.19/rpi3-32bit but it was with musl,
> since musl enabled 64bit time_t by default, that might be different
> issue too
>
> Try applying [1] to glibc as well, currrently, its only applied to musl
> case, perhaps that might help.
>
> [1]
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0022-Use-INT_MAX-instead-of-TIME_T_MAX-for-timerfd_settim.patch
>

It looks like it's something that's now in the call path which is
tripping the seccomp filter on systemd-journald - if I comment
SystemCallFilter=@system-service then I can boot.

Just trying to figure out what syscall it is we're tripping over. What
I don't understand is why booting linux-yocto 4.19 inside qemu w/
systemd doesn't see this problem.


--
Alex Kiernan