One of the notable change is that previously test-sysusers.sh was installed
unconditionally, but now it is installed only when sysusers is enabled.
Another change is that test-sysv-generator is now re-introduced which
was mistakenly dropped by 6c713961ab.
It already required a lot of workarounds, since the busybox utilities
often work differently than their "full" counterparts, and putting
the container together using our "tools" is quite simple anyway.
As part of the build, we would populate build/test/sys/ using
sys-script.py, and then udev-test.p[ly] would create a tmpfs instance
on build/test/tmpfs and copy the sys tree to build/test/tmpfs/sys.
Also, we had udev-test.p[ly] which called test-udev. test-udev was
marked as a manual test and installed, but neither udev-test.p[ly] or
sys-script.py were.
test-udev is renamed to udev-rule-runner, which reduces confusion and
frees up the test-udev name. udev-test.py is renamed to test-udev.py.
All three files are now installed.
test-udev.py is modified to internally call sys-script.py to set up the
sys tree. Copying and creating it from scratch should take the same
amount of time. We avoid having a magic directory, everything is now
done underneath a temporary directory.
test-udev.py is now a normal installed test, and run-unit-tests.py will
pick it up. When test-udev.py is invoked from meson, the path to
udev-rule-runner is passed via envvar; when it is invoked via
run-unit-tests.py or directly, it looks for udev-rule-runner in a relative
path.
The goal of this whole change is to let Debian drop the 'udev' test.
It called sys-script.py and udev-test.pl from the source directory and
had to recreate a bunch of the logic. Now test-udev.py will now be called
via 'upstream'.
I tried to keep this a 1:1 rewrite with the same field names.
Nevertheless, some changes were made:
- exp_add_error and exp_rem_error are dropped. Those fields meant that
"./test-udev add <devpath>" actually succeeded, but symlinks were not
created, and exp_links was ignored and could contain bogus content.
Instead, exp_links and not_exp_links are adjusted to not contain
garbage and the tests check that "./test-udev add" succeeds and that
the links are as expected from exp_links and not_exp_links.
- cleanup was only used in one rule, and that rule was expected to fail,
so cleanup wasn't actually necessary. So the cleanup field and the
logic to call cleanup from individual tests is removed.
- a bunch of fields were set, but didn't seem to be connected to any
implementation: not_exp_name, not_exp_test.
e62acc3159 did a rewrite of some of the
tests and it seems that not_exp_test was added by mistake and
not_exp_name was left behind by mistake.
In Python, the field list is declared in the class, so it's harder to
assign an unused attribute. Those uses were converted to not_exp_links.
- in most rules, r"""…""" is used, so that escaping is not necessary.
- the logic to generate devices was only used in one place, and the
generator function also had provisions to handle arguments that were
never given. all_block_devs() is made much simpler.
- Descriptions that started with a capital letter were shortened
and lowercased.
- no special test case counting is done. pytest just counts the cases
(Rules objects).
- the output for failures is also removed. If something goes wrong, the
user can use pytest --pdb or such to debug the issue.
- perl version used a semaphore to manage udev runners, and would fork,
optionally wait a bit, and then start the runner. In the python
version, we just spawn them all and wait for them to exit. It's not
very convenient to call fork() from python, so instead the runner
was modified (in previous commit) to wait.
The test can be called as:
(cd build && sudo pytest -v ../test/udev-test.py)
sudo meson test -C build udev-test.py -v
I think this generally provides functionality that is close to the perl
version. It seems some of the checks are now more fully implemented.
Support for strace/gdb/valgrind is missing.
Runtime goes down: 8.36 s → 5.78 s.
testdata/ is shared by both the unit tests and the integration tests. Hence it
makes sense to place them right under /usr/lib/systemd/tests/ while the tests
themself are located under dedicated sub-directories:
/usr/lib/systemd/tests/
├── integration-tests
├── testdata
└── unit-tests
├── testdata -> ../testdata
However the unit tests implemented as shell scripts (such as
test-fstab-generator.sh) expect to find testdata/ where the scripts are
installed, ie they do something like:
src="$(dirname "$0")/testdata/test-fstab-generator"
This patch installs a symlink in 'unitestsdir' named "testdata" and that points
to whatever value 'testdata_dir' is set.
/usr/lib/systemd/tests may contain more than the unit tests. For example on
SUSE we also install the integration tests there.
Putting the unit tests in a dedicated directory named 'unit-tests' makes the
layout cleaner.
Note that `run-unit-tests.py` has not been moved so we don't need to adjust
(Fedora) packaging and users also don't need to descend into the subdirectory.
The test files are /proc//auxv files copies from various architecutres
signified by the file name suffix.
Those tests are fairly simple, but when we run them on n architectures, we do
~n² cross-arch tests.
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
When mkosi is run from git-worktree(1), the .git is not a repository
directory but a textfile pointing to the real git dir
(e.g. /home/user/systemd/.git/worktrees/systemd-worktree). This git dir
is not bind mounted into build environment and it fails with:
> fatal: not a git repository: /home/user/systemd/.git/worktrees/systemd-worktree
> test/meson.build:190:16: ERROR: Command `/usr/bin/env -u GIT_WORK_TREE /usr/bin/git --git-dir=/root/src/.git ls-files ':/test/dmidecode-dumps/*.bin'` failed with status 128.
There is already a fallback to use shell globbing instead of ls-files,
use it with git worktrees as well.
Passing potentially arbitrary data into a shellscript is potentially
very broken if you do not correctly quote it for use. This quoting must
be done as part of the interpretation of the data itself, e.g. python's
shlex.quote; simply formatting it into a string with double quotes is
NOT sufficient.
An alternative is to communicate the data reliably via argv to the shell
process, and allow the shell to internally handle it via `"$1"`, which
is quote-safe and will expand the data from argv as a single tokenized
word.
This test has overlap with test-install-root, but it tests things at a
different level, so I think it's useful to add. It immediately shows various
bugs which will be fixed in later patches.
Make sure our RPM macros work as intended. Based on the original PR
(#16464) by Mikhail Novosyolov.
Co-authored-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Currently, running "meson build" followed by "meson test -C build"
will result in many failed tests due to missing dependencies. This
commit adds the missing dependencies to make sure no tests fail.
No need to invoke ls when we are just interested in file names.
Also, the cd to source root makes the output identical to
"git ls-files" (relative instead of absolute paths).
It picks the whole content of the directory by default, but we don't
want to install .gitattributes files. Add it to all invocations, not
just the ones on subdirs with .gitattributes, so that we don't regress
in the future.
Fixes#21715
This test makes assumptions on the availability of some mappings contained in
kbd-model-map and therefore strongly relies on the version shipped by
upstream. IOW the test is likely to fail if it's installed on a system with a
more comprehensive kbd-model-map.
This patch makes the upstream kbd-model-map file available via a symlink in
test/testdata/test-keymap-util dir and makes sure that this specific version is
always used by test-keymap-util regardless of whether the test is installed and
run on a different system or directly run (optionally via meson) from the
project working dir.
Fixes#17433. Currently, if any of the validations we do before we
check start rate limiting fail, we can still enter a busy loop as
no rate limiting gets applied. A common occurence of this scenario
is path units triggering a service that fails a condition check.
To fix the issue, we simply move up start rate limiting checks to
be the first thing we do when starting a unit. To achieve this,
we add a new method to the unit vtable and implement it for the
relevant unit types so that we can do the start rate limit checks
earlier on.
I wanted to use jinja2 templating here too, but it's hard to get right:
custom_target() strips the executable bit by default (unlike configure_file
apparently). custom_target() has install_mode setting, but it was only added
in meson-0.47, so it can't be used while we support 0.46. And without the
executable bit the test is not invoked properly. For example, "root-unittests"
in the debian package calls test-* after installation, so the executable bit
there is necessary. It would be possible to adjust the file mode after the
fact, but it would make things more complicated.
So let's use the native meson substitutions here. We don't need anything more
fancy.
Meson 0.58 has gotten quite bad with emitting a message every time
a quoted command is used:
Program /home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh found: YES (/home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program xsltproc found: YES (/usr/bin/xsltproc)
Configuring custom-entities.ent using configuration
Message: Skipping bootctl.1 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping journal-remote.conf.5 because HAVE_MICROHTTPD is false
Message: Skipping journal-upload.conf.5 because HAVE_MICROHTTPD is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping loader.conf.5 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
...
Let's suffer one message only for each command. Hopefully we can silence
even this when https://github.com/mesonbuild/meson/issues/8642 is
resolved.
https://github.com/systemd/systemd/pull/19316 failed with:
[1065/1670] Linking target systemd-hwdb
--- command ---
14:28:29 /root/src/test/hwdb-test.sh
--- stdout ---
./systemd-hwdb does not exist, please build first
I'm not sure what is going on here… In principle meson says that tests may be
called from any directory, but in practice is was always the build directory.
So far we were relying on systemd-hwdb being present in '.', and this worked.
Either way, it's nicer to pass the exact path, so let's do that.
Normally ls-files prints the full path to files from the repo root. But when
$GIT_WORK_TREE is set, ls-files prints paths relative to the current
directory. When rebasing, $GIT_WORK_TREE is set in the commands executed from
'rebase -x'. This causes problems if meson config is touched and the meson
reconfigures itself. ($GIT_WORK_TREE shouldn't be relevant, since the paths that
ls-files reports don't depend on the work tree, but whatever.) Let's unset
GIT_WORK_TREE to avoid the issue.
$ (cd test; git --git-dir=$PWD/../.git ls-files ':/test/dmidecode-dumps/*.bin')
test/dmidecode-dumps/HP-Z600.bin
test/dmidecode-dumps/Lenovo-ThinkPad-X280.bin
test/dmidecode-dumps/Lenovo-Thinkcentre-m720s.bin
$ (cd test; GIT_WORK_TREE=$PWD/.. git --git-dir=$PWD/../.git ls-files ':/test/dmidecode-dumps/*.bin')
dmidecode-dumps/HP-Z600.bin
dmidecode-dumps/Lenovo-ThinkPad-X280.bin
dmidecode-dumps/Lenovo-Thinkcentre-m720s.bin
Fixes#18148.
This allows them to be executed in parallel and also gives us
better reporting.
The dump files are renamed to avoid repeating "dmidecode-dump", since that
string is already present in the subdirectory name.
Add memory_id program to set properties about the physical memory
devices in the system. This is useful on machines with removable memory
modules to show how the machine can be upgraded, and on all devices to
detect the actual RAM size, without relying on the OS accessible amount.
Closes: #16651
All this test does is manipulate text files in a subdir specified with --testroot.
It can be a normal unittest without the overhead of creating a machine image.
As a bonus, also test the .standalone version.
The two timezone files are now installed in the global setup. I am not too
happy about this, but it still seems better than to create a completely
separate image just for this.
Unfortunately meson does not install symlinks, but copies the symlink
destination instead. So symlinks need to be created by a script.
This commit adds both symlinks in test/testsuite-08.units/ and meson
scriptlet calls. Strictly speaking, the first is not necessary, since nothing
reads stuff directly from the source tree.
The man pages state that the '+' prefix in Exec* directives should
ignore filesystem namespacing options such as PrivateTmp. Now it does.
This is very similar to #8842, just with PrivateTmp instead of
PrivateDevices.
job_compare return value is undefined in case the jobs have a loop
between them, so better make a test to make sure transaction cycle
detection catches it.
The test-engine Test2 tests the cycle detection when units a, b and d
all start at once
,-------------------after-----------------,
v |
a/start ---after---> d/start ---after---> b/start
Extend the test with Test11 that adds i.service which causes a and d
stop (by unordered Conflicts=) while starting b. Because stops precede
starts, we effectively eliminate the job cycle and all transaction jobs
should be applicable.
,-------------------after-----------------,
v |
a/stop <---after--- d/stop <---after--- b/start
. . ^
. . |
'. . . . . . . . . i/start ---after------'
In cgroup v2 we have protection tunables -- currently MemoryLow and
MemoryMin (there will be more in future for other resources, too). The
design of these protection tunables requires not only intermediate
cgroups to propagate protections, but also the units at the leaf of that
resource's operation to accept it (by setting MemoryLow or MemoryMin).
This makes sense from an low-level API design perspective, but it's a
good idea to also have a higher-level abstraction that can, by default,
propagate these resources to children recursively. In this patch, this
happens by having descendants set memory.low to N if their ancestor has
DefaultMemoryLow=N -- assuming they don't set a separate MemoryLow
value.
Any affected unit can opt out of this propagation by manually setting
`MemoryLow` to some value in its unit configuration. A unit can also
stop further propagation by setting `DefaultMemoryLow=` with no
argument. This removes further propagation in the subtree, but has no
effect on the unit itself (for that, use `MemoryLow=0`).
Our use case in production is simplifying the configuration of machines
which heavily rely on memory protection tunables, but currently require
tweaking a huge number of unit files to make that a reality. This
directive makes that significantly less fragile, and decreases the risk
of misconfiguration.
After this patch is merged, I will implement DefaultMemoryMin= using the
same principles.
Some controllers (like the CPU controller) have a performance cost that
is non-trivial on certain workloads. While this can be mitigated and
improved to an extent, there will for some controllers always be some
overheads associated with the benefits gained from the controller.
Inside Facebook, the fix applied has been to disable the CPU controller
forcibly with `cgroup_disable=cpu` on the kernel command line.
This presents a problem: to disable or reenable the controller, a reboot
is required, but this is quite cumbersome and slow to do for many
thousands of machines, especially machines where disabling/enabling a
stateful service on a machine is a matter of several minutes.
Currently systemd provides some configuration knobs for these in the
form of `[Default]CPUAccounting`, `[Default]MemoryAccounting`, and the
like. The limitation of these is that Default*Accounting is overrideable
by individual services, of which any one could decide to reenable a
controller within the hierarchy at any point just by using a controller
feature implicitly (eg. `CPUWeight`), even if the use of that CPU
feature could just be opportunistic. Since many services are provided by
the distribution, or by upstream teams at a particular organisation,
it's not a sustainable solution to simply try to find and remove
offending directives from these units.
This commit presents a more direct solution -- a DisableControllers=
directive that forcibly disallows a controller from being enabled within
a subtree.
There isn't really much need to keep them separate. Anything which is a good
corpus entry can be used as a smoke test, and anything which which is a
regression test can just as well be inserted into the corpus.
The only functional difference from this patch (apart from different paths in
output) is that the regression tests are now zipped together with the rest of
the corpus.
$ meson configure build -Dslow-tests=true && ninja -C build test
...
307/325 fuzz-dns-packet:issue-7888:address OK 0.06 s
308/325 fuzz-dns-packet:oss-fuzz-5465:address OK 0.04 s
309/325 fuzz-journal-remote:crash-5a8f03d4c3a46fcded39527084f437e8e4b54b76:address OK 0.07 s
310/325 fuzz-journal-remote:crash-96dee870ea66d03e89ac321eee28ea63a9b9aa45:address OK 0.05 s
311/325 fuzz-journal-remote:oss-fuzz-8659:address OK 0.05 s
312/325 fuzz-journal-remote:oss-fuzz-8686:address OK 0.07 s
313/325 fuzz-unit-file:oss-fuzz-6884:address OK 0.06 s
314/325 fuzz-unit-file:oss-fuzz-6885:address OK 0.05 s
315/325 fuzz-unit-file:oss-fuzz-6886:address OK 0.05 s
316/325 fuzz-unit-file:oss-fuzz-6892:address OK 0.05 s
317/325 fuzz-unit-file:oss-fuzz-6897:address OK 0.05 s
318/325 fuzz-unit-file:oss-fuzz-6897-evverx:address OK 0.06 s
319/325 fuzz-unit-file:oss-fuzz-6908:address OK 0.07 s
320/325 fuzz-unit-file:oss-fuzz-6917:address OK 0.07 s
321/325 fuzz-unit-file:oss-fuzz-6977:address OK 0.13 s
322/325 fuzz-unit-file:oss-fuzz-6977-unminimized:address OK 0.12 s
323/325 fuzz-unit-file:oss-fuzz-7004:address OK 0.05 s
324/325 fuzz-unit-file:oss-fuzz-8064:address OK 0.05 s
325/325 fuzz-unit-file:oss-fuzz-8827:address OK 0.52 s
We have "installed tests", but don't provide an easy way to run them.
The protocol is very simple: each test must return 0 for success, 77 means
"skipped", anything else is an error. In addition, we want to print test
output only if the test failed.
I wrote this simple script. It is pretty basic, but implements the functions
listed above. Since it is written in python it should be easy to add option
parsing (like running only specific tests, or running unsafe tests, etc.)
I looked at the following alternatives:
- Ubuntu root-unittests: this works, but just dumps all output to the terminal,
has no coloring.
- @ssahani's test runner [2]
It uses the unittest library and the test suite was implented as a class, and
doesn't implement any of the functions listed above.
- cram [3,4]
cram runs our tests, but does not understand the "ignore the output" part,
has not support for our magic skip code (it uses hardcoded 80 instead),
and seems dead upstream.
- meson test
Here the idea would be to provide an almost-empty meson.build file under
/usr/lib/systemd/tests/ that would just define all the tests. This would
allow us to reuse the test runner we use normally. Unfortunately meson requires
a build directory and configuration to be done before running tests. This
would be possible, but seems a lot of effort to just run a few binaries.
[1] 242c96addb/debian/tests/root-unittests
[2] https://github.com/systemd/systemd-fedora-ci/blob/master/upstream/systemd-upstream-tests.py
[3] https://bitheap.org/cram/
[4] https://pypi.org/project/pytest-cram/Fixes#10069.
Back in 08318a2c5a, value "false" was enabled for
'-Dtests=', but various tests were not conditionalized properly. So even with
-Dtests=false -Dslow-tests=false we'd run 120 tests. Let's make this consistent.
Absolute paths make everything simple and quick, but sometimes this requirement
can be annoying. A good example is calling 'test', which will be located in
/usr/bin/ or /bin depending on the distro. The need the provide the full path
makes it harder a portable unit file in such cases.
This patch uses a fixed search path (DEFAULT_PATH which was already used as the
default value of $PATH), and if a non-absolute file name is found, it is
immediately resolved to a full path using this search path when the unit is
loaded. After that, everything behaves as if an absolute path was specified. In
particular, the executable must exist when the unit is loaded.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
