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

[Alex Kiernan]

On Mon, Feb 3, 2020 at 10:17 PM Stefan Agner <stefan at agner.ch> wrote:
>
> Hi All,
>
> On 2020-01-27 16:14, Alex Kiernan wrote:
> > 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 am seeing this on master branch too on a Toradex Apalis iMX6 (i.MX
> 6Dual to be specfic) running a mainline kernel 5.4.2.
>
> We do have a RTC and according to dmesg the time has been read from it
> successfully and correctly. We do have a second (the SoC internal) which
> actually might be not correctly set, I haven't checked.
>
> It seems systemd-journald which is tripping, but later also
> systemd-udevd:
> [    5.749612] systemd-journald[510]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
> [    6.433771] systemd-journald[534]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
> [    6.934304] systemd-journald[536]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
> [    7.379449] systemd-journald[538]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
> [    7.763130] systemd-journald[539]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
> ...
> [    8.402258] systemd-udevd[542]: Assertion
> 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
> src/basic/time-util.c:55, function now(). Aborting.
>
> We do have +SECCOMP, and also here commenting out
> "SystemCallFilter=@system-service" seems to help.
>
> strace seems to point to clock_gettime64:
>

That fits with systemd-243.4 fixing it - there's a commit in there
which adds clock_gettime64 to @system-service.

-- 
Alex Kiernan