IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The usage of an initrd made TEST-09-ISSUE-2691 more likely to fail with
a timeout, so increase the timeout by 90s and adjust TimeoutStopSec=
accordingly.
Not all distros support booting without an initrd. E.g. the Debian
kernel builds ext4 as a module and so relies on an initrd to
successfully start the QEMU-based images.
Mount tmpfses over the networkd and resolved config and state
directories, and stop the services beforehand. This ensures that the
test does not mess with an existing networkd/resolved setup. At least
for ethernet setups, this does not sever existing links, so is good
enough for the CI cases we are interested in (QEMU and LXC).
Relax the skip check to only skip the test when trying to run this on
real iron, but start running it in virtual machines now.
This allows us to run the test on Ubuntu 18.04 LTS in CI, which uses
both services by default.
Like s-networkd.service itself, it can happen that s-resolved.service
runs into restart limits. Don't enforce a successful call, as on
machines without resolved the unit might not be loaded.
- Reset systemd-networkd.service before each test run, to avoid running
into restart limits.
- Our networkd-test-router.service unit needs to run as root and thus
can't use `User=`; but networkd still insists on the
`systemd-network` system user to exist, so create it.
oss-fuzz flags this as:
==1==WARNING: MemorySanitizer: use-of-uninitialized-value
0. 0x7fce77519ca5 in ascii_is_valid systemd/src/basic/utf8.c:252:9
1. 0x7fce774d203c in ellipsize_mem systemd/src/basic/string-util.c:544:13
2. 0x7fce7730a299 in print_multiline systemd/src/shared/logs-show.c:244:37
3. 0x7fce772ffdf3 in output_short systemd/src/shared/logs-show.c:495:25
4. 0x7fce772f5a27 in show_journal_entry systemd/src/shared/logs-show.c:1077:15
5. 0x7fce772f66ad in show_journal systemd/src/shared/logs-show.c:1164:29
6. 0x4a2fa0 in LLVMFuzzerTestOneInput systemd/src/fuzz/fuzz-journal-remote.c:64:21
...
I didn't reproduce the issue, but this looks like an obvious error: the length
is specified, so we shouldn't use the string with any functions for normal
C-strings.
The test is heavily dependent on timeouts, and if we are run in
potentially very slow QEMU instances there's a good chance we'll miss
some which we normally wouldn't miss. Hence, let's test this one in
nspawn only. Given that the test is purely in service management it
shouldn't matter whether it runs in nspawn or qemu, hence keep running
it in nspawn, but don't bother with qemu.
Similar, do this for TEST-03-JOBS, too, which operates with relatively
short sleep times internally.
Fixes: #9123
As it turns out /usr/share/selinux/devel/ is now included in more RPMs
than just selinux-policy-devel (specifically container-selinux, which is
pulled in by various container related RPMs). Let's hence tighten the
dependency check a bit and look for systemd's .if file, which is what we
actually care about.
First, ellipsize() and ellipsize_mem() should not read past the input
buffer. Those functions take an explicit length for the input data, so they
should not assume that the buffer is terminated by a nul.
Second, ellipsization was off in various cases where wide on multi-byte
characters were used.
We had some basic test for ellipsize(), but apparently it wasn't enough to
catch more serious cases.
Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8686.
journalctl -o short would display those entries, but journalctl -o short-full
would refuse. If the entry is bad, just fall back to the receive-side realtime
timestamp like we would if it was completely missing.
We'd look for a '=' separator using memchr, i.e. ignoring any nul bytes in the
string, but then do a strndup, which would terminate on any nul byte, and then
again do a memcmp, which would access memory past the chunk allocated by strndup.
Of course, we probably shouldn't allow keys with nul bytes in them. But we
currently do, so there might be journal files like that out there. So let's fix
the journal-reading code first.
Something is wrong with the entry (probably a missing timestamp), so no point
in rotating. But suppress the error in process_source(), so that the processing
of the data stream continues.
Also, just return 0 from writer_write() on success, the only caller doesn't
care.
This corresponds nicely with the specifiers we already pass for
/var/lib, /var/cache, /run and so on.
This is particular useful to update the test-path service files to
operate without guessable files, thus allowing multiple parallel
test-path invocations to pass without issues (the idea is to set $TMPDIR
early on in the test to some private directory, and then only use the
new %T or %V specifier to refer to it).
Test the "[Bridge]" section keys
```
[Bridge]
UnicastFlood=true
HairPin=true
UseBPDU=true
FastLeave=true
AllowPortToBeRoot=true
Cost=555
Priority=23
```
```
test_bridge_init (__main__.BridgeTest) ... ok
test_bridge_port_priority (__main__.BridgeTest) ... ok
test_bridge_port_priority_set_zero (__main__.BridgeTest)
It should be possible to set the bridge port priority to 0 ... ok
test_bridge_port_property (__main__.BridgeTest)
Test the "[Bridge]" section keys ... ok
```
Yes, the output is sometimes annyoing, but /dev/null is not the right
place...
I figure this redirection was left in from some debugging session, let's
fix it, and make the setup_basic_environment invocation like in all
other test scripts.
Nested KVM is very flaky as we learnt from our CI. Hence, let's avoid
KVM whenever we detect we are already running inside of KVM.
Maybe one day nested KVM is fixed, at which point we can turn this on
again, but for now let's simply avoid nested KVM, since reliable CI is
more important than quick CI, I guess.
And yes, avoiding KVM for our qemu runs does make things substantially
slower, but I think it's not a complete loss.
Inspired by @evverx' findings in:
https://github.com/systemd/systemd/pull/8701#issuecomment-380213302
