It seems that on Semaphore CI, running in Bullseye images, having
both Network-Manager and systemd-networkd enabled causes
'systemctl start network-online.target' to get stuck, and fail
the run. Disable networkd in those tests.
See: https://github.com/systemd/systemd/issues/22991
Without `--plain` `systemctl` prints a circle (●) in the first column
for each failed service, which with the current code interferes with
attempted journal listing for each such service:
```
test_no_failed (__main__.ServicesTest)
No failed units ... -------- journal for failed service ● -----------
Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?).
-- Journal begins at Sun 2021-04-25 03:05:23 UTC, ends at Sun 2021-04-25 09:00:32 UTC. --
-- No entries --
FAIL
```
The test currently looks for the first(ish) kernel log message, which may
not be present. If it's not, the test case fails.
This isn't the fault of systemd/journald, the problem is the kernel filled
up its klog buffer before we started journald to read them. This can be
caused by a too-small kernel klog buffer, or could be caused by a large
number of kernel boot-time messages. More details are in this Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479
While catching all the kernel log messages since boot is important, this
test case is testing systemd, not the kernel, and should not fail if
the kernel's log buffer is filling during boot.
This problem has caused upstream systemd to disable Ubuntu CI on arm64
for many months:
https://github.com/systemd/systemd/issues/11104Closes: #929730
BugLink: https://bugs.launchpad.net/bugs/1831296
The test case was checking for a failing result of 'code=killed', but
the recent change now causes the failure to be 'code=dumped'. The
test should pass if the result is either.
- Skip tests which can't work in containers.
- Add missing rsyslog test dependency.
- e2scrub_reap.service fails in containers, ignore (filed as #926138)
- Relax pgrep pattern for gdm, as there's no wayland session in
containers.
Use their $AUTOPKGTEST_* equivalents.
These were introduced in autopkgtest 4.0 (June 2016), and all our CI
systems use a much newer version.
Gbp-Dch: Short
So far, we tried to avoid cleaning up manually created cgroups via a
Debian specific patch. This patch was dropped though and that particular
use case was never really supported upstream.
As this would trigger an autopkgtest failure now, let's remove this test.
Follow-up for commit 9738816398.
Gbp-Dch: Short
Verify that CLI programs have a sane behaviour and exit code when being called
with --help, --version, or an invalid option.
This reproduces #843509 aka. issue #4605.
- /run/lock is already created differently by
Make-run-lock-tmpfs-an-API-fs.patch, and contradicts to that.
- /run/lock/lockdev/ isn't being used anywhere and will be dropped
upstream soon; apply that patch separately as
tmpfiles-drop-run-lock-lockdev.patch.
- Move dropping of "group:wheel" (which has never existed in Debian) into
debian/rules, to also catch occurrences in other parts of the file which
the static patch would overlook. This should ideally be fixed upstream
(https://github.com/systemd/systemd/issues/2492)
Remove the hack in debian/tests/boot-and-services as this is now unnecessary.
Skip tests which are known to fail/not applicable with testing upstream builds.
In that mode, fix the groups in tmpfiles.d files which don't exist on Debian
(to be fixed upstream).
For this we currently need some seddery in tmpfiles.d/, until they get fixed
upstream.
Don't check for "Requesting system poweroff" log message in nspawn test,
current upstream master does not write that any more. Instead check for
"Stopped Container c1".
Wait until bash crash stack trace is in the journal before asserting on it.
Also relax RE to work on non-x86 architectures. On e. g. ppc64el we merely get
Stack trace of thread 1091:
#0 0x00003fff9ad4f3b8 kill (libc.so.6)
#1 0x0000000010068370 kill_pid (bash)
This also adds a test for /var/tmp/ cleanup. As
Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch disables /var/tmp/
cleanup (see Debian #675422), comment out that check.
This reproduces #779169.
