318/365 fuzz-bus-message:crash-26bba7182dedc8848939931d9fcefcb7922f2e56:address OK 0.03 s
319/365 fuzz-bus-message:crash-29ed3c202e0ffade3cad42c8bbeb6cc68a21eb8e:address OK 0.03 s
320/365 fuzz-bus-message:crash-b88ad9ecf4aacf4a0caca5b5543953265367f084:address OK 0.03 s
321/365 fuzz-bus-message:crash-c1b37b4729b42c0c05b23cba4eed5d8102498a1e:address OK 0.03 s
322/365 fuzz-bus-message:crash-d8f3941c74219b4c03532c9b244d5ea539c61af5:address OK 0.03 s
323/365 fuzz-bus-message:crash-e1b811da5ca494e494b77c6bd8e1c2f2989425c5:address OK 0.03 s
324/365 fuzz-bus-message:leak-c09c0e2256d43bc5e2d02748c8d8760e7bc25d20:address OK 0.04 s
325/365 fuzz-bus-message:message1:address OK 0.03 s
326/365 fuzz-bus-message:timeout-08ee8f6446a4064db064e8e0b3d220147f7d0b5b:address OK 0.03 s
327/365 fuzz-dhcp-server:discover-existing:address OK 0.04 s
328/365 fuzz-dhcp-server:discover-new:address OK 0.03 s
329/365 fuzz-dhcp-server:release:address OK 0.04 s
330/365 fuzz-dhcp-server:request-existing:address OK 0.03 s
331/365 fuzz-dhcp-server:request-new:address OK 0.03 s
332/365 fuzz-dhcp-server:request-reboot:address OK 0.03 s
333/365 fuzz-dhcp-server:request-renew:address OK 0.03 s
334/365 fuzz-dns-packet:issue-7888:address OK 0.03 s
335/365 fuzz-dns-packet:oss-fuzz-5465:address OK 0.03 s
336/365 fuzz-journal-remote:crash-5a8f03d4c3a46fcded39527084f437e8e4b54b76:address OK 0.06 s
337/365 fuzz-journal-remote:crash-96dee870ea66d03e89ac321eee28ea63a9b9aa45:address OK 0.04 s
338/365 fuzz-journal-remote:invalid-ts.txt:address OK 0.04 s
339/365 fuzz-journal-remote:oss-fuzz-8659:address OK 0.06 s
340/365 fuzz-journal-remote:oss-fuzz-8686:address OK 0.04 s
341/365 fuzz-journal-remote:sample.txt:address OK 0.07 s
342/365 fuzz-unit-file:directives.service:address OK 0.03 s
343/365 fuzz-unit-file:empty.scope:address OK 0.04 s
344/365 fuzz-unit-file:machine.slice:address OK 0.03 s
345/365 fuzz-unit-file:oss-fuzz-6884:address OK 0.05 s
346/365 fuzz-unit-file:oss-fuzz-6885:address OK 0.03 s
347/365 fuzz-unit-file:oss-fuzz-6886:address OK 0.04 s
348/365 fuzz-unit-file:oss-fuzz-6892:address OK 0.03 s
349/365 fuzz-unit-file:oss-fuzz-6897:address OK 0.05 s
350/365 fuzz-unit-file:oss-fuzz-6897-evverx:address OK 0.04 s
351/365 fuzz-unit-file:oss-fuzz-6908:address OK 0.05 s
352/365 fuzz-unit-file:oss-fuzz-6917:address OK 0.06 s
353/365 fuzz-unit-file:oss-fuzz-6977:address OK 0.08 s
354/365 fuzz-unit-file:oss-fuzz-6977-unminimized:address OK 0.10 s
355/365 fuzz-unit-file:oss-fuzz-7004:address OK 0.03 s
356/365 fuzz-unit-file:oss-fuzz-8064:address OK 0.03 s
357/365 fuzz-unit-file:oss-fuzz-8827:address OK 0.50 s
358/365 fuzz-unit-file:proc-sys-fs-binfmt_misc.automount:address OK 0.03 s
359/365 fuzz-unit-file:syslog.socket:address OK 0.03 s
360/365 fuzz-unit-file:systemd-ask-password-console.path:address OK 0.03 s
361/365 fuzz-unit-file:systemd-machined.service:address OK 0.03 s
362/365 fuzz-unit-file:systemd-resolved.service:address OK 0.03 s
363/365 fuzz-unit-file:systemd-tmpfiles-clean.timer:address OK 0.03 s
364/365 fuzz-unit-file:timers.target:address OK 0.03 s
365/365 fuzz-unit-file:var-lib-machines.mount:address OK 0.04 s
This gives us slightly nicer coverage in the normal test run.
When in a git repo, git ls-files is used to get a list of files known to git.
This mirrors what update-man-rules does for man files. Only looking at files
known to git makes it easier to not forget to commit the test file to git,
and also makes bisecting easier if some files are left in repo.
When outside of a git repo, we expect to be unpacked from a tarball, so just
using all files reported by ls is OK.
In the main meson.build file, .source_root() and .current_source_dir() are
equivalent, but it seems more appropriate to use .source_root() when we are appending
a path which is by design relative to repo root.
The justification is the same as for -Dvalgrind: setting config in
meson in this way is easier, because when the value is changed stuff
that should be rebuilt is rebuilt.
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
Yes, there are still a lot of users of bzip2, but it's fallen out of
favour after LZMA/xz, which can compress a lot more and often
decompresses faster than bzip2 too.
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.
We would have a strange situation where after setting -Dslow-tests=true -Dtests=false
we'd get mostly the slow tests (plus some other ones which I'll fix in
subsequent commit). Let's simplify things by making -Dtests=false just
disable those tests too.
This makes it so that tests no longer need to know the absolute paths to the
source and build dirs, instead using the systemd-runtest.env file to get these
paths when running from the build tree.
Confirmed that test-catalog works on `ninja test`, when called standalone and
also when the environment file is not present, in which case it will use the
installed location under /usr/lib/systemd/catalog.
The location can now also be overridden for this test by setting the
$SYSTEMD_CATALOG_DIR environment variable.
This simplifies get_testdata_dir() to simply checking for an environment
variable, with an additional function to locate a systemd-runtest.env file in
the same directory as the test binary and reading environment variable
assignments from that file if it exists.
This makes it possible to:
- Run `ninja test` from the build dir and have it use ${srcdir}/test for
test unit definitions.
- Run a test directly, such as `build/test-execute` and have it locate
them correctly.
- Run installed tests (from systemd-tests package) and locate the test
units in the installed location (/usr/lib/systemd/tests/testdata), in
which case the absence of the systemd-runtest.env file will have
get_testdata_dir() use the installed location hardcoded into the
binaries.
Explicit setting of $SYSTEMD_TEST_DATA still overrides the contents of
systemd-runtest.env.
Starting with meson 0.46, it is able to detect these argument correctly.
See this commit in meson codebase for more details:
695b8f3a03
We already carry a requirement for meson_version : '>= 0.46', so we can be sure
our build system will include this commit.
Tested by building systemd using a cloned meson synced to the 0.46.0 tag,
confirmed the warnings were detected correctly in that case. The meson messages included this snippet:
> Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: YES
> Compiler for C supports arguments -Wno-missing-field-initializers -Wmissing-field-initializers: YES
> Compiler for C supports arguments -Wno-unused-result -Wunused-result: YES
> Compiler for C supports arguments -Wno-format-signedness -Wformat-signedness: YES
> Compiler for C supports arguments -Wno-error=nonnull -Werror=nonnull: YES
> Compiler for C supports arguments -Wno-maybe-uninitialized -Wmaybe-uninitialized: YES
The docs/ directory is special in GitHub, since it can be used to serve GitHub
Pages from, so there's a benefit to switching to it in order to expose it
directly as a website.
Updated references to it from the documentations themselves, from the
CONTRIBUTING.md file and from Meson build files.
Compiler flag -Wmaybe-uninitialized is quite noisy and produces many false
positives, especially when optimization flags are enabled (tested gcc 8.2.1),
so let's just disable it in systemd build.
For example, with CFLAGS=-O2, the build produces 11 such warnings and the
default CFLAGS of Fedora's rpmbuild warns about it in 176 places. A look at a
sample of those shows that most are false positives, where the compiler just
can't figure it out correctly. (While fixing those would be nice, I'm not sure
it's a good use of our time.)
The noisy [-Wmaybe-uninitialized] warnings are not just an annoyance, since
they make it harder to spot warnings that indicate actual problems (such as
variable declared but not used.) Silencing those is beneficial, so that
contributors would see warnings where there are actually actionable problems,
so there's a better chance of having those issues addressed before a PR is
pushed.
Tested:
$ CFLAGS='-O2 -Wp,-D_FORTIFY_SOURCE=2' meson build/
$ ninja -C build/
(NOTE: -Wp,-D_FORTIFY_SOURCE=2 prevents [-Wstringop-truncation] warnings.)
With the commands above, the build will not produce any [-Wmaybe-uninitialized]
warnings (or any other warnings), which is not really the case before this commit.
Also tested with rpmbuild on Fedora, after this commit there are no warnings
produced in the build step.
This work add support to generic netlink to sd-netlink.
See https://lwn.net/Articles/208755/
networkd: add support FooOverUDP support to IPIP tunnel netdev
https://lwn.net/Articles/614348/
Example conf:
/lib/systemd/network/1-fou-tunnel.netdev
```
[NetDev]
Name=fou-tun
Kind=fou
[FooOverUDP]
Port=5555
Protocol=4
```
/lib/systemd/network/ipip-tunnel.netdev
```
[NetDev]
Name=ipip-tun
Kind=ipip
[Tunnel]
Independent=true
Local=10.65.208.212
Remote=10.65.208.211
FooOverUDP=true
FOUDestinationPort=5555
```
$ ip -d link show ipip-tun
```
5: ipip-tun@NONE: <POINTOPOINT,NOARP> mtu 1472 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ipip 10.65.208.212 peer 10.65.208.211 promiscuity 0
ipip remote 10.65.208.211 local 10.65.208.212 ttl inherit pmtudisc encap fou encap-sport auto encap-dport 5555 noencap-csum noencap-csum6 noencap-remcsum numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
```
Meson does not care either way, so let's use the simpler syntax. And files()
already gives a list, so nesting this in a list wouldn't be necessary even
if meson did not flatten everything.
This provides basic OpenSSL support without optimizations like TCP Fast Open and TLS Session Tickets.
Notice only a single SSL library can be enabled at a time and therefore journald functions provided by GnuTLS will be disabled when using OpenSSL.
Fixes#9531
This bumps the minimum required version of meson to 0.45 and
python to 3.5, as integer type option is supported since meson-0.45
and meson-0.45 requires python-3.5.
This adds -Dnss-resolve= and -Dnss-mymachines= meson options.
By using this option, e.g., resolved can be built without nss-resolve.
When no nss modules are built, then test-nss is neither built.
Also, This changes the option name -Dmyhostname= to -Dnss-myhostname=
for consistency to other nss related options.
Closes#9596.
Using `getent' and `id' command in case of cross compiling does not
make much sense. This is because it is the host files that are checked.
Besides, in some restricted cross compilation environment, these two
command may not even be available. This is to avoid host comtamination.
So we should only check the validity using getent and id when not
cross compiling.
key_serial_t is defined in keyutil.h, which wasn't included in the header list
in the test, so the test always failed. We were always compiling stuff with
!HAVE_KEY_SERIAL_T.
We could try to add keyutil.h to the test, but then we'd have to first check if
it is available, which just doesn't seem worth the trouble.
key_serial_t should always be defined as int32_t. Let's keep the uncoditional
define, since repeated compatible typedefs are not a problem, and it allows us
to compile even if the header file is missing. If there's ever a change in the
definition, we'll have to adjust the code for the different type anyway, and
our compiler will tell us.
Using _GNU_SOURCE is better because that's how we include the headers in the
actual build, and some headers define different stuff when it is defined.
sys/stat.h for example defines 'struct statx' conditionally.
Starting with glibc 2.27.9000-36.fc29, include file sys/stat.h will have a
definition for struct statx, in which case include file linux/stat.h should be
avoided, in order to prevent a duplicate definition.
In file included from ../src/basic/missing.h:18,
from ../src/basic/util.h:28,
from ../src/basic/hashmap.h:10,
from ../src/shared/bus-util.h:12,
from ../src/libsystemd/sd-bus/bus-creds.c:11:
/usr/include/linux/stat.h:99:8: error: redefinition of ‘struct statx’
struct statx {
^~~~~
In file included from /usr/include/sys/stat.h:446,
from ../src/basic/util.h:19,
from ../src/basic/hashmap.h:10,
from ../src/shared/bus-util.h:12,
from ../src/libsystemd/sd-bus/bus-creds.c:11:
/usr/include/bits/statx.h:36:8: note: originally defined here
struct statx
^~~~~
Extend our meson.build to look for struct statx when only sys/stat.h is
included and, in that case, do not include linux/stat.h anymore.
Tested that systemd builds correctly when using a glibc version that includes a
definition for struct statx.
glibc Fedora RPM update:
28cb5d31fc
glibc upstream commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fd70af45528d59a00eb3190ef6706cb299488fcd
This fixes the following warning:
```
meson.build:1140: WARNING: Trying to compare values of different types (DependencyHolder, list) using !=.
The result of this is undefined and will become a hard error in a future Meson release.
```
Follow-up for f02582f69fe1e7663a87ba80bd4f90d5d23ee75f(#9410).
../src/test/test-sizeof.c: In function ‘main’:
../src/test/test-sizeof.c:70:24: error: result of ‘1 << 31’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Werror=shift-overflow=]
X = (1 << 31),
^~
cc1: some warnings being treated as errors
Follow-up for b05ecb8cad.
The primary motivation is to catch enum values created through a shift that is
too big:
../src/test/test-sizeof.c:26:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
enum_with_shift = 1 << 32,
^~
cc1: some warnings being treated as errors
The compiler will now reject those.
This is an alternative to #9224.
We already allowed variables to be declared in the middle of a function
(whenever a new scope was opened), so this isn't such a big change. Sometimes
we would open a scope just to work around this prohibition.
But sometimes the code can be much clearer if the variable is declared
somewhere in the middle of a scope, in particular if the declaration is
combined with initialization or acquisition of some resources. So let's allow
this, but keep things in the old style, unless there's a good reason to move
the variable declaration to a different place.
Systemctl is special because it is required for many tasks that may need to
be performed when the system is not fully configured and/or partially
broken:
1. Installing/Uninstalling services during OS installs and upgrades
2. Shutting down the system
Therefore reduce the number of dependencies that systemctl pulls in, by
not linking to systemd-shared. This brings a bit of resilience to
systemctl (and its aliases shutdown, reboot, etc), by linking against
less external libraries.
Because this extra resilience comes at a cost of approximately 580 KB
extra space, this is done behind a meson build option.
Lennart Poettering