systemctl uints look fishy on big-endian (looks fine with gdbus)

[xnox]

Submission type

• [ X ] Bug report

systemd version the issue has been seen with

229

Used distribution

Ubuntu

In case of bug report: Expected behaviour you didn't see

With

$ gdbus introspect --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 --only-properties | grep -e NFailedUnits -e NJobs
      readonly u NFailedUnits = 1;
      readonly u NJobs = 0;

I expect

$ systemctl status | head
...
    State: degraded
     Jobs: 0 queued
   Failed: 1 units

In case of bug report: Unexpected behaviour you saw

In actually I saw:

    State: degraded
     Jobs: 3654160039 queued
   Failed: 3654160039 units

Imho the numbers should match the gdbus enquiry.

In case of bug report: Steps to reproduce the problem

$ systemctl status

On a big-endian machine.

[martinpitt]

Confirmed on the s390x box for autopkgtesting. At least gdbus and busctl agree:

$ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1 | grep -e NFailedUnits -e NFailedJobs -e NJobs
.NFailedJobs                        property  u                131074                                   -
.NFailedUnits                       property  u                1                                        emits-change
.NJobs                              property  u                0                                        -

$ gdbus introspect --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 --only-properties | grep -e NFailedUnits -e NFailedJobs -e NJobs
      readonly u NFailedUnits = 1;
      readonly u NJobs = 0;
      readonly u NFailedJobs = 131074;

The 131074 (0x20002) looks suspicious too, but not sure what counts as failed job, and this machine has been running for quite some time already. But indeed the numbers in systemctl status are totally off too:

     Jobs: 2741101651 queued
   Failed: 2741101651 units

So this mostly just looks like a presentation/conversion issue in systemctl. I'll take a look.

[martinpitt]

Frustratingly this works fine with -O0. It's not just the wrong %u (which needs to be PRIu32), the values already come out garbled from bus_map_all_properties().

[poettering]

Looks like a serious bug on BE systems. I don't see any obvious bug with the LE/BE conversion here though, I figure somebody with access to a BE system needs to debug bus_map_all_properties() properly...

[martinpitt]

Turned out to be quite shallow after all, see linked PR.