Comment 24 for bug 1829829

Looking at the latest 20 i386 tests, I see failing tests for 12888, 12884, 12912, 12918, and 12919.

PR 12884 looks like it's adding a new test, TEST-35, so I'll assume that test just needs more work.

PR 12888 failed once, but there are 3 later tests that all pass, so I assume it's ok now.

PR 12919 appears to have failed while building upstream systemd, so I assume that's a problem with the PR.

PR 12912 passed once, but then was run again and failed due to TEST-34 timing out.
PR 12918 failed also with TEST-34 timing out.

However, these aren't failing because they just didn't have enough time to run. They are failing because they are running "systemd-run --wait" but the --wait never completes, even though the service finishes. This is what I was talking about before when I mentioned that dbus (bus-api-system) appears to be crashing/restarting. Note in the failing test upstream-stdout:

$ grep -E '(bus-api-system|run-u7)' upstream-stdout
...
run-u7.service: Installed new job run-u7.service/start as 322
run-u7.service: Enqueued job run-u7.service/start as 322
Bus bus-api-system: changing state RUNNING → CLOSING
Bus bus-api-system: changing state CLOSING → CLOSED
Bus bus-api-system: changing state UNSET → OPENING
Bus bus-api-system: changing state OPENING → AUTHENTICATING
run-u7.service: Failed to set 'memory.min' attribute on '/system.slice/run-u7.service' to '0': No such file or directory
run-u7.service: Failed to set 'memory.swap.max' attribute on '/system.slice/run-u7.service' to 'max': No such file or directory
run-u7.service: Failed to set 'memory.oom.group' attribute on '/system.slice/run-u7.service' to '0': No such file or directory
run-u7.service: Passing 0 fds to service
run-u7.service: About to execute: /usr/bin/test -f /var/lib/zzz/test
run-u7.service: Forked /usr/bin/test as 274
run-u7.service: Changed dead -> runningFound pre-existing private StateDirectory= directory /var/lib/private/zzz, migrating to /var/lib/zzz.
run-u7.service: Job 322 run-u7.service/start finished, result=done
run-u7.service: Executing: /usr/bin/test -f /var/lib/zzz/testsystemd-journald.service: Got notification message from PID 210 (WATCHDOG=1)
run-u7.service: Child 274 belongs to run-u7.service.
run-u7.service: Main process exited, code=exited, status=0/SUCCESS
run-u7.service: Succeeded.
run-u7.service: Changed running -> dead
run-u7.service: Consumed 59ms CPU time.
run-u7.service: Collecting.
Bus bus-api-system: changing state AUTHENTICATING → HELLO
Bus bus-api-system: changing state HELLO → RUNNING

It looks like bus-api-system is down when the service completes, and the notification that it finished never reaches the system-run --wait caller (the testsuite), so the testsuite just hangs doing nothing until the test timeout.