| Commit message (Collapse) | Author | Files | Lines |
|---|
|
When compiled with -O2, the compiler is not happy about dynamic_user_pop() and
would warn about the output variables not being set. It does have a point:
we were doing a cast from ssize_t to int, and theoretically there could be
wraparound. So let's add an explicit check that the cast to int is fine.
[540/2509] Compiling C object src/core/libsystemd-core-256.so.p/dynamic-user.c.o
../src/core/dynamic-user.c: In function ‘dynamic_user_close.isra’:
../src/core/dynamic-user.c:580:9: warning: ‘uid’ may be used uninitialized [-Wmaybe-uninitialized]
580 | unlink_uid_lock(lock_fd, uid, d->name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/core/dynamic-user.c:560:15: note: ‘uid’ was declared here
560 | uid_t uid;
| ^~~
../src/core/dynamic-user.c: In function ‘dynamic_user_realize’:
../src/core/dynamic-user.c:476:29: warning: ‘new_uid’ may be used uninitialized [-Wmaybe-uninitialized]
476 | num = new_uid;
| ~~~~^~~~~~~~~
../src/core/dynamic-user.c:398:23: note: ‘new_uid’ was declared here
398 | uid_t new_uid;
| ^~~~~~~
|
|
Since e56a8790a0 debugging test-execute fails has been a royal PITA, since
we ditch all potentially useful output from the test units (that, for
the most part, run `sh -x ...`). Let's improve the situation a bit by
setting EXEC_OUTPUT_NULL only when running the single test case that
needs it, and inheriting stdout otherwise.
For example, with a purposefully introduced error we get this output
with this patch:
exec-personality-x86-64.service: About to execute: sh -x -c "c=\$\$(uname -m); test \"\$\$c\" = \"foo_bar\""
Serializing sd-executor-state to memfd.
...
Personality: x86-64
LockPersonality: no
SystemCallErrorNumber: kill
++ uname -m
+ c=x86_64
+ test x86_64 = foo_bar
Received SIGCHLD from PID 1520588 (sh).
Child 1520588 (sh) died (code=exited, status=1/FAILURE)
exec-personality-x86-64.service: Child 1520588 belongs to exec-personality-x86-64.service.
exec-personality-x86-64.service: Main process exited, code=exited, status=1/FAILURE
exec-personality-x86-64.service: Failed with result 'exit-code'.
...
Exit Status: 1
src/test/test-execute.c:456:test_exec_personality: exec-personality-x86-64.service: can_unshare=yes: exit status 1, expected 0
(test-execute-root) terminated by signal ABRT.
Assertion 'r >= 0' failed at src/test/test-execute.c:1433, function prepare_ns(). Aborting.
Aborted
But without it, we'd miss the most important part:
exec-personality-x86-64.service: About to execute: sh -x -c "c=\$\$(uname -m); test \"\$\$c\" = \"foo_bar\""
Serializing sd-executor-state to memfd.
...
Personality: x86-64
LockPersonality: no
SystemCallErrorNumber: kill
Received SIGCHLD from PID 1521365 (sh).
Child 1521365 (sh) died (code=exited, status=1/FAILURE)
exec-personality-x86-64.service: Child 1521365 belongs to exec-personality-x86-64.service.
exec-personality-x86-64.service: Main process exited, code=exited, status=1/FAILURE
exec-personality-x86-64.service: Failed with result 'exit-code'.
...
Exit Status: 1
src/test/test-execute.c:456:test_exec_personality: exec-personality-x86-64.service: can_unshare=yes: exit status 1, expected 0
(test-execute-root) terminated by signal ABRT.
Assertion 'r >= 0' failed at src/test/test-execute.c:1433, function prepare_ns(). Aborting.
Aborted
|
|
|
|
|
|
|
|
Currently, the memory management of service_set_main_pidref
is a bit odd. Normally we either invalidate the original
resource on caller's side after the call succeeds, or
just pass the ownership wholly. But service_set_main_pidref
take a pointer, and calls pidref_done() internally.
Let's just make it consume the passed pidref. This is more
straightforward.
|
|
Addresses https://github.com/systemd/systemd/pull/31986#discussion_r1554053623
|
|
Addresses https://github.com/systemd/systemd/pull/31435#discussion_r1553969156
Co-authored-by: Lennart Poettering <lennart@poettering.net>
|
|
On s390x both __s390__ and __s390x__ are defined, and with the original
order we'd go through the __s390__ branch and emit a warning:
[169/2118] Compiling C object src/shared/libsystemd-shared-256.a.p/base-filesystem.c.o
../src/shared/base-filesystem.c:136:11: note: ‘#pragma message: Please add an entry above specifying whether your architecture uses /lib64/, /lib32/, or no such links.’
136 | # pragma message "Please add an entry above specifying whether your architecture uses /lib64/, /lib32/, or no such links."
| ^~~~~~~
|
|
If we're running test-execute from the build directory which is under
one of the tmpfs-ed directories (i.e. /root or /tmp), test-execute might
behave strangely, since in that case manager_new() pins the system
systemd-executor binary instead of the build dir one, which may lead to
a very confusing test fails (if there's enough difference between the
system and built sd-executor binary). Let's account for that and
bind-mount the build dir under the tmpfs-ed directory if necessary.
|
|
On s390x this test fails when the SUT uses the z90crypt kernel module,
as it's an another FD the test doesn't account for:
/* test_rearrange_stdio */
Successfully forked off 'rearrange' as PID 57293.
test_rearrange_stdio: r=0
/proc/57293/fd:
total 0
lrwx------. 1 root root 64 Apr 5 06:18 0 -> /dev/pts/0
lrwx------. 1 root root 64 Apr 5 06:18 1 -> /dev/pts/0
lrwx------. 1 root root 64 Apr 5 06:18 2 -> /dev/pts/0
lrwx------. 1 root root 64 Apr 5 06:18 3 -> /dev/z90crypt
rearrange terminated by signal ABRT.
Debugging this was pain, since the child process didn't log anything
once we closed stdout/stderr (for obvious reasons). Let's fix both
issues by switching logging to kmsg once we close stdin/stdout/stderr,
and also by making the test work fine when there are some extra FDs in
the child's environment.
|
|
Fixes 6ea51363c8e39fb0924dda972a212936456a2b4f
|
|
|
|
Currently, when downgrading from a version with pidfd support to a
version without pidfd support, all information about running processes
is lost as the newer systemd will serialized pidfds which are not recognized
by the older systemd when deserializing.
To improve the situation, let's serialize both the pid and the pidfd.
This is safe because existing versions will either replace the first
deserialized pidref with the second one or discard the second one in
favor of the first one depending on the unit and field. Older versions
that don't support pidfd's will silently discard any fields that contain
a pidfd as those will try to parse the field as a pid and since a pidfd
field will start with '@', those versions will debug error log and ignore
the value.
To make sure we reuse the existing pidfd as much as possible, the pidfd
is serialized first. Both for scopes and service main pids, if the same
pid is seen multiple times, the first pidref is kept. So by serializing
the pidfd first we make sure the original pidfd is used instead of the
new one which is opened when deserializing the first pid field.
For other control units, older versions with pidfd support will discard
the first pidfd and replace it with a new pidfd from the second pid field.
This is a slight regression on downgrades, but we make sure it doesn't
happen for future versions (and older versions when this commit is
backported) by modifying the logic to only use the first successfully
deserialized pidref so that the raw pid without pidfd is discarded instead
of it replacing the existing pidfd.
|
|
There are bugs in the kernel verifier that cause legitimate code
to be rejected, disabling this optimization makes bpf programs
built with a new enough gcc work again.
Fixes https://github.com/systemd/systemd/issues/31888
|
|
Missing colon prevents this from working correctly on the Chuwi UBook X and UBook X Pro.
|
|
Follow-up for 03b6879f4d45c49264708aef872fd05af30ddcf0.
|
|
Follow-up for e0504dd011189d97a1ea813aabfe1e696742bcf5.
Hopefully, devices in PCI subsystem have some properties, thus have
their udev database file. But, that may not be true. Here, we only read
sysattrs of enumerated devices, hence it is not necessary to check if
the device is initialized or not.
|
|
Follow-up for 089bef66316e5bdc91b9984148e5a6455449c1da.
|
|
|
|
|
|
Addresses post-merge comment:
https://github.com/systemd/systemd/commit/03b6879f4d45c49264708aef872fd05af30ddcf0#r140587790
|
|
Requested for the testing of F40 riscv bringup. Numbers copied from
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/.
It'd be nice to do the same in TEST-58, but the code there is rather involved
and I don't have a system to test on. We can probably try that later on when F40
is available.
|
|
|
|
Closes #28421.
|
|
|
|
This adds basic support of receiving and parsing Neighbor Advertisement
message defined in RFC 4861.
|
|
The order of the arguments of the function `acquire_luks2_key()` in
`luks2-tpm2.h` is wrong, `pcrlock_path` and `pin` are swapped.
Fixes 404aea7815595c1324947ed7f2a7502b17d3cc01
|
|
When enumerated devices are being processed by udevd, we will receive
corresponding uevents later. So, we should not process devices in that
case.
|
|
|
|
And make it also check the existence of the udev database.
|
|
|
|
As it turns out libkmod has quite a bunch of deps, including various
compressing libs and similar. By turning this into a dlopen()
dependency, we can make our depchain during install time quite a bit
smaller. In particular as inside of containers kmod doesn't help anyway
as CAP_SYS_MODULE is not available anyway.
While we are at it, also share the code that sets up logging/kmod
context.
After:
$ lddtree ./build/systemd
systemd => ./build/systemd (interpreter => /lib64/ld-linux-x86-64.so.2)
libsystemd-core-255.so => ./build/src/core/libsystemd-core-255.so
libaudit.so.1 => /lib64/libaudit.so.1
libcap-ng.so.0 => /lib64/libcap-ng.so.0
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
libm.so.6 => /lib64/libm.so.6
libmount.so.1 => /lib64/libmount.so.1
libblkid.so.1 => /lib64/libblkid.so.1
libseccomp.so.2 => /lib64/libseccomp.so.2
libselinux.so.1 => /lib64/libselinux.so.1
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0
libsystemd-shared-255.so => /home/lennart/projects/systemd/build/src/shared/libsystemd-shared-255.so
libacl.so.1 => /lib64/libacl.so.1
libattr.so.1 => /lib64/libattr.so.1
libcap.so.2 => /lib64/libcap.so.2
libcrypt.so.2 => /lib64/libcrypt.so.2
libgcrypt.so.20 => /lib64/libgcrypt.so.20
libgpg-error.so.0 => /lib64/libgpg-error.so.0
liblz4.so.1 => /lib64/liblz4.so.1
libcrypto.so.3 => /lib64/libcrypto.so.3
libz.so.1 => /lib64/libz.so.1
libpam.so.0 => /lib64/libpam.so.0
libeconf.so.0 => /lib64/libeconf.so.0
liblzma.so.5 => /lib64/liblzma.so.5
libzstd.so.1 => /lib64/libzstd.so.1
libc.so.6 => /lib64/libc.so.6
Before:
$ lddtree ./build/systemd
systemd => ./build/systemd (interpreter => /lib64/ld-linux-x86-64.so.2)
libsystemd-core-255.so => ./build/src/core/libsystemd-core-255.so
libaudit.so.1 => /lib64/libaudit.so.1
libcap-ng.so.0 => /lib64/libcap-ng.so.0
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
libkmod.so.2 => /lib64/libkmod.so.2
libzstd.so.1 => /lib64/libzstd.so.1
liblzma.so.5 => /lib64/liblzma.so.5
libz.so.1 => /lib64/libz.so.1
libcrypto.so.3 => /lib64/libcrypto.so.3
libgcc_s.so.1 => /lib64/libgcc_s.so.1
libm.so.6 => /lib64/libm.so.6
libmount.so.1 => /lib64/libmount.so.1
libblkid.so.1 => /lib64/libblkid.so.1
libseccomp.so.2 => /lib64/libseccomp.so.2
libselinux.so.1 => /lib64/libselinux.so.1
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0
libsystemd-shared-255.so => /home/lennart/projects/systemd/build/src/shared/libsystemd-shared-255.so
libacl.so.1 => /lib64/libacl.so.1
libattr.so.1 => /lib64/libattr.so.1
libcap.so.2 => /lib64/libcap.so.2
libcrypt.so.2 => /lib64/libcrypt.so.2
libgcrypt.so.20 => /lib64/libgcrypt.so.20
libgpg-error.so.0 => /lib64/libgpg-error.so.0
liblz4.so.1 => /lib64/liblz4.so.1
libpam.so.0 => /lib64/libpam.so.0
libeconf.so.0 => /lib64/libeconf.so.0
libc.so.6 => /lib64/libc.so.6
|
|
This makes sure we mention the word "watchdog" in every log message
related to the watchdog.
Also, this uses the expression "hardware timeout" when referring to the
primary timeout of the watchdog, as opposed to the "pretimeout".
(Not ideal wording I know, but it's preexisting to some point, I just
continued it. I think it's OK though, in particular to underline the
difference to the software watchdog logic we implement via WATCHDOG= in
sd_notify().)
Fixes: #31662
|
|
These allow adding extra units and drop-ins via credentials.
|
|
We stick to debug logging because in some cases network-generator
will fall back to trying another parsing function if one fails, so
if we return an error it's not necessarily a failure.
|
|
I think this way it's easier to see that they are part of the same argument.
|
|
This is just good style. In this particular case, if the argument is incorrect and
the function is not tested with $NOTIFY_SOCKET set, the user could not get the
proper error until running for real.
Also, remove mention of systemd. The protocol is fully generic on purpose.
|
|
Fixup for dfad86b83807fa8696ca94982a5ba591b6d86a80.
|
|
F40 will be out soon, so we can update the man page already. The example should
already work.
The cloud link was dropped in fd571c9df0ba86636401582c4ea0a8cb608e1216, so
drop the unused variable too.
|
|
|
|
|
|
- Install individual asan libraries instead of gcc
- Drop duplicate qrencode package from arch config
- Install dbus-user-session which provides default-dbus-session-bus
- Explicitly install dbus-broker on Arch Linux
|
|
All code around this does this too, hence do it here as well.
Also fix plural verb form.
Follow-up for: #32018
|
|
Unfortunately, sd-bus-vtable.h, sd-journal.h, and sd-id128.h
have variadic macro and inline initialization of sub-object, these are
not supported in C90. So, we need to silence some errors.
|
|
Also install setools-console and policycoreutils instead of setools
which pulls in the kitchen sink. Also install selinux-policy-targeted
to make sure the right policy is installed.
|
|
This avoids pulling in the perl kitchen sink.
|
|
This reverts commit 85b774de49caff8be819f021740dd680ba76ab77.
|
|
method call
Fixes: #32066
|
|
At that point the options have been parsed, sent and received again so
`ndisc_parse_options` should never fail there (unless ndisc_send corrupts
them somehow).
It's a follow-up to https://github.com/systemd/systemd/pull/31807
|
