This applies an (upstreamed) patch to permit systemd-localed to run
locale-gen to generate missing locale when requested to switch the
system locale.
This makes localectl usable on Debian for changing locale without
breaking system localization or even prevent certain applications from
running at all after switching to a non-generated locale.
We are not really interested in the return code and error messages from
dbus-monitor after killing it, so ignore them to avoid undesired
autopkgtest failures.
Follow-up for commit 3de342799c.
Unconditionally back up/restore locale configuration files and generate
en_US.UTF-8. Previously the test failed in environments which have some
locale other than en_US.UTF-8 in /etc/default/locale.
Also fix the assertion of /etc/locale.conf not being present after
localectl. This only applies to Debian/Ubuntu tests, not upstream ones
(see Use-Debian-specific-config-files.patch)
Some kernels in Ubuntu (e.g. linux-kvm) do not enable CONFIG_PM, which
results in stderr output when the logind test tries to grep the power
state file, causing the test to fail. The test already handles skipping
the test if suspend isn't supported, so just use -s to suppress grep
from printing to stderr if the file doesn't exist.
Currently, the 'upstream' test runs all upstream-provided tests at tests/TEST-*,
except for any that are in a hardcoded list contained in this test.
Any change to the hardcoded blacklist involves patching the debian repo, which is
not an ideal way for upstream systemd to manage a hopefully temporary blacklist of
problematic tests.
There was discussion around making the blacklist entirely provided by an upstream
env var, configured in the upstream webhooks that control the Ubuntu CI tests,
but that results in 2 problems; 1) Debian would no longer be able to easily
control its own blacklist, and 2) upstream would only have an all-or-none control
over the blacklist, meaning that it could only enable or disable any specific
test for all PRs; it could not enable a test for only a specific PR that was
attempting to fix the flaky test (for example).
This approach moves blacklist control into the systemd tests themselves, by changing
the 'upstream' test to look for a file in the test directory, and skipping the test
if such file is found. This way, Debian (and Ubuntu and other Debian derivatives)
can continue to manage their own blacklist, but also upstream can control
the blacklist for individual tests on a per-PR basis.
For example, if upstream has the file 'tests/TEST-01-BASIC/blacklist-ubuntu-ci'
in its repo, Ubuntu CI will skip this test for all PRs opened. Then, a PR can
be opened that both fixes the test, as well as removes this file. The Ubuntu CI
will then run the test, but only for the PR that attempts to fix it. Once that
PR is merged, all future tests will then run the fixed test.
The specific naming of the per-test blacklist file, for tests run from the
upstream repo, is either "blacklist-ubuntu-ci" to completely blacklist the test
on all archs, or "blacklist-ubuntu-ci-$DPKGARCH" to blacklist the test only
for a specific arch, for example "blacklist-ubuntu-ci-amd64". For tests run
from Debian (or Ubuntu), which are run without the TEST_UPSTREAM param set,
the blacklist filename is 'blacklist-upstream-ci[-$DPKGARCH]'.
Note that the $DPKGARCH is specified as the value returned by
'dpkg --print-architecture', not the value returned from 'uname -m' (e.g.
to blacklist a test for intel 64-bit, 'amd64' should be used, not 'x86_64').
This naming matches the title of the ubuntu tests, such as 'bionic-amd64',
'bionic-arm64', etc.
polkit.service is started on-demand via D-Bus activation. This means it
is not a good indicator if a boot was successful. Instead check if
NetworkManager is running as it is started via multi-user.target.
Closes: #934992
The check for is-system-running handles verifying that systemd completes
all its jobs during startup, making this test redundant. Also, since the
testbed can (and does) start more jobs after is-system-running, this test
can provide a false negative if any of those jobs continue running after
this check's timeout.
There is currently no delay to wait for is-system-running to reach running
or degraded, so it's very possible for there to be running jobs. This adds
a delay until is-system-running is 'running' or 'degraded', and gathers
extra artifacts if the system is 'degraded'.
Additional details are in this Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997
Note that bug description states:
"This patch is not required for debian, because debian's boot-smoke does
not include the wait for systemctl is-system-running", however this patch
adds that wait, because without it, the check for running jobs can easily
fail, if the system isn't fully running yet.
A previous commit changed the plaintext_name to a unique per-test name,
so there is no need to match the ask_password content on 'scsi_debug' now,
since just matching the plaintext_name should be unique.
This removes the systemctl start, as the service should already be
running (or starting, or failed). Instead, just wait for the service
to actually reach 'active' or 'failed' state. Then, only stop the
service if its state is 'active'.
Previous attempts to fix hung or flaky test runs included adding a start
before the stop, but the start-the-stop calls can lead to cancelled jobs
instead of a properly stopped service, which is again flaky.
Setting the plaintext name to include the testname makes debugging failures
easier.
Also for convenience, create service_name field in setup method, for use
in tests and/or teardown method.
run the 'clean' target before setup/run, to match the upstream
'all' target's behavior; also the clean (again) target must be
run separately, as the failure of setup or run will stop make,
and cleanup won't be done if called in the same make line.
is-active return code isn't the correct way to verify a service is
fully stopped; instead use show --property=ActiveState to verify it
is 'inactive'
This also could use the text output of is-active, but (per manpage)
the show command is "intended to be used whenever computer-parsable
output is required."
systemctl is-active returns non-zero even while the service is
'deactivating', but not actually stopped, which allows the testcase
to fail intermittently on slow machines, if the service hasn't
actually stopped before reaching the check to verify the service
stopped.
For example:
$ systemctl is-active systemd-timesyncd
active
$ timedatectl set-ntp false ; systemctl is-active systemd-timesyncd ; echo $?
deactivating
3
So the test code which does:
$ while systemctl is-active --quiet systemd-timesyncd; do sleep 1; done
will never actually perform that sleep.
Unfortunately, these tests are failing on i386 builds, very
intermittently; this causes headaches for upstream systemd
maintainers and submitters, when the Ubuntu CI fails, because
the failure isn't related to the PRs the tests are running for,
and determining that from the Ubuntu CI log file and other artifacts
is very time-consuming.
This just blacklists the tests for now, until we can figure out why
they are failing and fix them.
TEST-30 is discussed:
https://github.com/systemd/systemd/issues/12268
TEST-34 is discussed:
https://github.com/systemd/systemd/issues/12932
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.
