Several test cases intentionally trigger assert_return(). So, to avoid
the entire test fails, this introduces several macros that tentatively
make assert_return() not critical.
Let's get networkd onto Varlink. This only adds the most basic of
operations.
I'd love to see networkd do Varlink for all its basic operations so that
networkctl can use that, and work correctly before D-Bus is up. Right
now, many of networkctls calls simply don't work before D-Bus, and I'd
like to see that improved.
This is gets the resource limits off a specified process, and is very
similar to prlimit() with a NULL new_rlimit argument. In fact, it tries
that first. However, it then falls back to use /proc/$PID/limits. Why?
Simply because Linux prohibits access to prlimit() for processes with a
different UID, but /proc/$PID/limits still works.
This is preparation to allow nspawn to run unprivileged.
The read-only bit is flipped after setting up all the mounts, so that
bind mounts can be added. Remove the early config, and add a unit
test.
Fixes https://github.com/systemd/systemd/issues/30372
When [Link] MTU= is specified in a .network file, we have no idea about
that what kind of interface will be configured with the .network file.
The maximum and minimum MTU size depend on the kind of interface.
So, we should not filter MTU eagerly in the parser.
Closes#30140.
Our timestamp conversion roundtrip test was failing. But I think that this
is not our bug:
$ TZ='Africa/Khartoum' date --date='@1509482094'
Tue Oct 31 23:34:54 EAT 2017
$ TZ='Africa/Khartoum' date --date='Tue Oct 31 23:34:54 EAT 2017' +%s
1509485694
$ TZ='Africa/Khartoum' date --date='@1509485694'
Tue Oct 31 23:34:54 CAT 2017
$ echo $[1509485694 - 1509482094]
3600
This is essentially the same as what happens in our test. After a round-trip, we
end up one hour ahead.
> For 1509482094632752, from the change log of tzdata:
>
> Release 2017c - 2017-10-20 14:49:34 -0700
>
> Changes to future timestamps
> Sudan will switch from +03 to +02 on 2017-11-01.
Fixes https://github.com/systemd/systemd/issues/28472.
The TPM2 tests that genreate an RSA primary key are fast on vtpms, but
very slow on physical TPMs, simply because TPMs aren't precisely fast
devices. It makes sense to keep the tests around however. Hence hide the
test behind the "slow test" logic by default – but only if we run on
physical hw, and keep them in place on VMs (where we'd expect a vtpm, if
any).
The test-tpm2 test multiplexes a bunch of tests from a single
entrypoint test that creates the TPM2 connection. This means we only get
the nice log output which test we are looking for once for the
entrypoint.
Let's add a macro that allows it to nicely generate it for the inner
tests too and use it.
Currently test_setpriority_closest assumes that setting RLIMIT_NICE to 30 will
fail if the process is unprivileged. If it succeeds, it assumes that the
process is privileged and setresuid and setresgid will succeed.
However, if RLIMIT_NICE is already >= 30, then setrlimit will succeed even if
the process is unprivileged. Guard against that by checking for permission
errors in setresuid and setresgid and skipping the full test if so.
Fixes#22896.
Lennart Poettering
Frantisek Sumsal
Yu Watanabe
Mike Yuan
Luca Boccassi
Daan De Meyer
Matteo Croce
ksaleem
Zbigniew Jędrzejewski-Szmek
Dan Nicholson