Try to make this more manageable by reording:
- dependencies / inputs
(with subcategory of compression libraries)
- major components / outputs
- optional features / conditionals that don't fit into the two above categories
The division isn't well defined, because libraries often correspond one-to-one
to feature, but not always.
test: use systemd-run --wait in TEST-44-LOG-NAMESPACE
The test appears to be occasionally failing. It uses systemd-run to echo
'hello world' into a namespaced journal and then uses journalctl to look for it,
but it doesn't wait.
In the failed runs it can't find it, but the automated journal dump shows
the message at the end.
As @yuwata correctly points out, this became broken when log_debug()
started returning -EIO. I wanted to preserve this pattern, but it turns
out it is not very widely used, and preserving it would make the whole
thing, already quite complicated, even more complex.
log_debug() is made like log_info() and friends, and returns void.
basic/log: assert that 0 is not passed as errno, except in test code
Let's assert if we ever happen to pass 0 to one of the log functions.
With the preceding commit to return -EIO from log_*(), passing 0 wouldn't
affect the return value any more, but it is still most likely an error.
The unit test code is an exception: we fairly often pass the return value
to print it, before checking what it is. So let's assert that we're not
passing 0 in non-test code. As with the previous check for %m, this is only
done in developer mode. We are depending on external code setting
errno correctly for us, which might not always be true, and which we can't
test, so we shouldn't assert, but just handle this gracefully.
I did a bunch of greps to try to figure out if there are any places where
we're passing 0 on purpose, and couldn't find any.
The one place that failed in tests is adjusted.
About "zerook" in the name: I wanted the suffix to be unambiguous. It's a
single "word" because each of the words in log_full_errno is also meaningful,
and having one term use two words would be confusing.
basic/log: assert that %m is not used when error is not set
This is only done in developer mode. It is a pretty rare occurence that we
make this kind of mistake. And even if it happens, the result is just a misleading
error message. So let's only do the check in non-release builds.
This silences some warnigns where gcc thinks that some variables are
unitialized. One particular case:
../src/journal/journald-server.c: In function 'ache_space_refresh':
../src/journal/journald-server.c:136:28: error: 'vfs_avail' may be used uninitialized in this function [-Werror=maybe-uninitialized]
136 | uint64_t vfs_used, vfs_avail, avail;
| ^~~~~~~~~
../src/journal/journald-server.c:136:18: error: 'vfs_used' may be used uninitialized in this function [-Werror=maybe-uninitialized]
136 | uint64_t vfs_used, vfs_avail, avail;
| ^~~~~~~~
cc1: all warnings being treated as errors
which is caused by
d = opendir(path);
if (!d)
return log_full_errno(errno == ENOENT ? LOG_DEBUG : LOG_ERR,
errno, "Failed to open %s: %m", path);
if (fstatvfs(dirfd(d), &ss) < 0)
return log_error_errno(errno, "Failed to fstatvfs(%s): %m", path);
For some reason on aarch64 gcc thinks we might return non-negative here. In
principle errno must be set in both cases, but it's hard to say for certain.
So let's make sure that our code flow is correct, even if somebody forgot to
set the global variable somewhere.
Using a enum is all nice and generic, but at this point it seems unlikely that
we'll add further build modes. But having an enum means that we need to include
the header file with the enumeration whenerever the conditional is used. I want
to use the conditional in log.h, which makes it hard to avoid circular imports.
tree-wide: avoid uninitialized warning on _cleanup_ variables
With some versions of the compiler, the _cleanup_ attr makes it think
the variable might be freed/closed when uninitialized, even though it
cannot happen. The added cost is small enough to be worth the benefit,
and optimized builds will help reduce it even further.
meson: build tests with -Wno-maybe-uninitialized if -O2/-flto are used
We intentionally do not inline initializations with definitions for
a bunch of _cleanup_ variables in tests, to ensure valgrind is triggered.
This triggers a lot of maybe-uninitialized false positives when -O2 and
-flto are used. Suppress them.
But, in some situation, people may want to manage routing policy rules
with other tools, e.g. 'ip' command. To support such the situation,
this introduce ManageForeignRoutingPolicyRules= boolean setting.
packit: drop the 'sources' file after cloning the Fedora repo
Otherwise rebase-helper thinks we're are a dist-git repository,
replacing the generated git archive with PR changes with the tarball
found in the 'sources' file.
There are two ambiguity in the original description:
1. It will delay all RUN instructions, include builtin.
2. It will delay before running RUN, not each of RUN{program} instructions.
The test occasionally fails as the umount is not yet completed when
cryptsetup close is invoked.
Both cryptsetup and losetup have supported deferred cleanup for some
time now, so use it instead to avoid races.
++ losetup -P --show --find /tmp/test-repart.dMOfYQ8UUF/zzz
+ LOOP=/dev/loop6
+ VOLUME=test-repart-11882
+ touch /tmp/test-repart.dMOfYQ8UUF/empty-password
+ cryptsetup open --type=luks2 --key-file=/tmp/test-repart.dMOfYQ8UUF/empty*** test-repart-11882
+ mkdir /tmp/test-repart.dMOfYQ8UUF/mount
+ mount -t ext4 /dev/mapper/test-repart-11882 /tmp/test-repart.dMOfYQ8UUF/mount
+ diff -r /tmp/test-repart.dMOfYQ8UUF/mount/def /tmp/test-repart.dMOfYQ8UUF/definitions
+ umount /tmp/test-repart.dMOfYQ8UUF/mount
+ cryptsetup close test-repart-11882
Device test-repart-11882 is still in use.
+ rm -rf /tmp/test-repart.dMOfYQ8UUF
Julia Kartseva [Wed, 9 Dec 2020 06:07:30 +0000 (22:07 -0800)]
dbus-cgroup: add BPFProgram= dbus support
- Handle BPFProgram= property in string format
"<bpf_attach_type>:<bpffs_path>", e.g. egress:/sys/fs/bpf/egress-hook.
- Add dbus getter to list foreign bpf programs attached to a cgroup.
Julia Kartseva [Wed, 4 Sep 2019 02:08:13 +0000 (19:08 -0700)]
tests: add unit file tests for BPFProgram=
- Pin trivial bpf programs to bpf filesystem, compose BPFProgram= option
string and pass it to a unit. Programs store `0` in r0 BPF register for
denying action, e.g. drop a packet.
- Load trivial BPF programs
- Test is skipped if not run under root or if can not lock enough
memory.
- For egress and ingress hooks, test BPFProgram= option along with
with IP{Egress|Ingress}FilterPath=, expected result should not depend on
which rule is executed first.
Expected results for BPF_CGROUP_INET_INGRESS:
5 packets transmitted, 0 received, 100% packet loss, time 89ms
For BPF_CGROUP_INET_SOCK_CREATE:
ping: socket: Operation not permitted
Julia Kartseva [Wed, 16 Sep 2020 22:58:04 +0000 (15:58 -0700)]
core: add bpf-foreign unit helpers
- Introduce support of cgroup-bpf programs managed (i.e. compiled,
loaded to and unloaded from kernel) externally. Systemd is only
responsible for attaching programs to unit cgroup hence the name
'foreign'.
Foreign BPF programs are identified by bpf program ID and attach type.
systemd:
- Gets kernel FD of BPF program;
- Makes a unique identifier of BPF program from BPF attach type and
program ID. Same program IDs mean the same program, i.e the same
chunk of kernel memory. Even if the same program is passed multiple
times, identical (program_id, attach_type) instances are collapsed
into one;
- Attaches programs to unit cgroup.
Julia Kartseva [Tue, 2 Mar 2021 00:56:04 +0000 (16:56 -0800)]
cgroup: add foreign program to cgroup context
- Store foreign bpf programs in cgroup context. A program is considered
foreign if it was loaded to a kernel by an entity external to systemd,
so systemd is responsible only for attach and detach paths.
- Support the case of pinned bpf programs: pinning to bpffs so a program
is kept loaded to the kernel even when program fd is closed by a user
application is a common way to extend program's lifetime.
- Aadd linked list node struct with attach type and bpffs path
fields.
projects / thirdparty / systemd.git / log
