If you start editing a shell script and then open a buffer with a C
file, the shiftwidth set by the previous autocommand for the sh file
type would not be reset to the original (global) 8ch. Let's fix this by
explicitly setting the shiftwidth in the C file type autocommand as
well.
When exiting PID 1 we most likely don't have stdio/stdout open, so the
final LSan check would not print any actionable information and would
just crash PID 1 leading up to a kernel panic, which is a bit annoying.
Let's instead attempt to open /dev/console, and if we succeed redirect
LSan's report there.
The result is a bit messy, as it's slightly interleaved with the kernel
panic, but it's definitely better than not having the stack trace at
all:
[ OK ] Reached target final.target.
[ OK ] Finished systemd-poweroff.service.
[ OK ] Reached target poweroff.target.
=================================================================
3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1
==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
[ 43.254683] Call Trace:
[ 43.254911] <TASK>
[ 43.255107] dump_stack_lvl+0x47/0x60
S[ a 43.n2555i05] panic+t0x192/0x350
izer[ :43.255966 ] do_exit+0x990/0xdb10
etec[ 43.256504] do_group_exit+0x31/0x80
[ 43.256889] __x64_sys_exit_group+0x18/0x20
[ 43.257288] do_syscall_64+0x60/0x90
o_user_mod leaks[ 43.257618] ? syscall_exit_t
+0x2b/0x40
[ 43.258411] ? do_syscall_64+0x6c/0x90
1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180
[ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 43.259901] RiIP: 0033:0x7f357nb8f3ad4
1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051
[ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd
[ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001
[ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef
[ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000
[ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007
[ 43.267517] </TASK>
#0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f)
#1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132
#2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190
#3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234
#4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734
#5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621
#6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406
#7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319
#8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439
#9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007
#10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049
#11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269
#12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296
#13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638
#14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187
#15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808
#16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869
#17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244
#18 0x41db21 in invoke_main_loop ../src/core/main.c:1960
#19 0x426615 in main ../src/core/main.c:3125
#20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a)
SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).
[ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---
Originally noticed in https://github.com/systemd/systemd/pull/28579.
Otherwise we'll get stuck waiting indefinitely if the test socket unit
fails to fail due the trigger limit, i.e.:
[ 111.104906] testsuite-07.sh[743]: + systemctl start issue2467.socket
[ OK ] Listening on issue2467.socket.
[ 111.746465] testsuite-07.sh[743]: + nc -w20 -U /run/test.ctl
Starting systemd-tmpfiles-clean.service...
[ OK ] Finished systemd-tmpfiles-clean.service.
qemu-system-x86_64: terminating on signal 15 from pid 565814 (timeout)
E: Test timed out after 1800s
With the idle timeout we should give up after 20 seconds, allowing the next
statement to properly fail:
[ 34.233084] testsuite-07.sh[450]: + systemctl start issue2467.socket
[ 35.475392] testsuite-07.sh[450]: + nc -i20 -w20 -U /run/test.ctl
[ 56.122941] testsuite-07.sh[458]: Ncat: Idle timeout expired (20000 ms).
[ 56.140871] testsuite-07.sh[450]: + :
[ 56.145460] testsuite-07.sh[450]: + timeout 10 bash -c 'while ! [[ "$(systemctl show issue2467.socket -P ActiveState)" == failed ]]; do sleep .5; done'
[ 66.197623] testsuite-07.sh[446]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/testsuite-07.issue-2467.sh failed'
In file included from ../src/basic/macro.h:455,
from ../src/basic/alloc-util.h:10,
from ../src/basic/hash-funcs.h:4,
from ../src/basic/hashmap.h:8,
from ../src/shared/dns-domain.h:10,
from ../src/network/networkd-radv.c:9:
../src/network/networkd-radv.c: In function ‘config_parse_router_home_agent_lifetime’:
../src/network/networkd-radv.c:1626:28: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 11 has type ‘long long unsigned int’ [-Werror=format=]
1626 | "Invalid %s= must be in the range 1...%lu seconds, ignoring: %s", lvalue,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/basic/log.h:361:125: note: in definition of macro ‘log_syntax’
361 | ? log_syntax_internal(unit, _level, config_file, config_line, _e, PROJECT_FILE, __LINE__, __func__, __VA_ARGS__) \
| ^~~~~~~~~~~
../src/network/networkd-radv.c:1626:68: note: format string is defined here
1626 | "Invalid %s= must be in the range 1...%lu seconds, ignoring: %s", lvalue,
| ~~^
| |
| long unsigned int
| %llu
cc1: all warnings being treated as errors
Addresses: https://github.com/systemd/systemd/pull/28964#issuecomment-1705550404
Follow-up to 6a6d27bc5b.
The pipe stuff introduced in 701e0c2660 causes nspawn to switch the
console from 'interactive' into 'read-only' which is a bit useless when
debugging. Let's set --console=interactive explicitly in such case.
Follow-up to 701e0c2660.
Handle the case when all the arguments are passed in through a
configuration file:
$ cat ukify.conf
[UKI]
Linux = /boot/vmlinuz-linux
Initrd = /boot/initramfs-linux.img
Before:
$ src/ukify/ukify.py --config ukify.conf build
Traceback (most recent call last):
File "/root/systemd/src/ukify/ukify.py", line 1604, in <module>
main()
File "/root/systemd/src/ukify/ukify.py", line 1590, in main
opts = parse_args()
^^^^^^^^^^^^
File "/root/systemd/src/ukify/ukify.py", line 1584, in parse_args
apply_config(opts)
File "/root/systemd/src/ukify/ukify.py", line 1431, in apply_config
item.apply_config(namespace, section_name, group, key, value)
File "/root/systemd/src/ukify/ukify.py", line 1123, in apply_config
self.config_push(namespace, group, dest, value)
File "/root/systemd/src/ukify/ukify.py", line 1019, in config_list_prepend
setattr(namespace, dest, value + old)
~~~~~~^~~~~
TypeError: can only concatenate list (not "NoneType") to list
After:
$ src/ukify/ukify.py --config ukify.conf build
Kernel version not specified, starting autodetection 😖.
Found uname version: 6.4.7-arch1-3
Wrote unsigned vmlinuz-linux.unsigned.efi
Resolves: #28688
Same scenario as with libsystemd - ldd might use unprefixed RPATH, and
we install our own stuff into the image unconditionally anyway.
Also, bail out early if we hit a missing DSO with a possibly helpful
message.
Since not all fields of the dispatch table are mandatory we might end up
reading garbage if the optional field is not set.
In CIs we were lucky enough (or probably unfortunate enough) that the
garbage was printable, but in other cases the `show-server-state` verb
would just fail with:
$ resolvectl show-server-state
Failed to print table: Invalid argument
Follow-up to bc837621a3.
If we don't have TPM support then `alg` is NULL and passing this to
table_new() means we'd get a table with only two columns instead of
three, leading up to a very confusing output:
$ build/systemd-analyze pcrs
System lacks full TPM2 support, not showing PCR state.
NR NAME
0 platform-code
- 1
platform-config -
2 external-code
- 3
external-config -
4 boot-loader-code
- 5
boot-loader-config -
6 -
- 7
...
Let's name the header in this case with a simple dash, as it's going
to be hidden anyway, to make the table nice again:
$ build/systemd-analyze pcrs
System lacks full TPM2 support, not showing PCR state.
NR NAME
0 platform-code
1 platform-config
2 external-code
3 external-config
4 boot-loader-code
5 boot-loader-config
6 -
7 secure-boot-policy
...
To avoid apt complaining:
+ apt-get -y install clang-15 lldb-15 lld-15 clangd-15
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python3-lldb-14 : Conflicts: python3-lldb-x.y
python3-lldb-15 : Conflicts: python3-lldb-x.y
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
Otherwise bad things happen:
systemd-networkd[3140]: wlan0: Saved new link: ifindex=5, iftype=ETHER(1), kind=n/a
systemd-networkd[3140]: Assertion '(_error) != 0' failed at src/network/networkd-wifi.c:119, function manager_genl_process_nl80211_config(). Aborting.
Resolves: #28534
Since 7c764d4 we bind mount certain directories during switch root
instead of moving the mount directly, and for /run we do this without
MS_REC. This, unfortunately, leaves all mounts under /run behind
in the old root, which breaks certain use cases.
See: https://github.com/systemd/systemd/issues/28452
This fixes regression introduced in 5a0c810462 with which all requests
for link properties ended up with EINVAL as we kept hitting
the signature_is_single() assert in sd_bus_get_property().
It's been a while since we introduced Differential ShellCheck and it
proved to be quite useful (and in some ways even better than the shellcheck
run by super-linter). So, to have only one linter scream at us for not
knowing how to write bash properly, let's drop the super-linter's one in
favor of Differential ShellCheck.
Follow-up for https://github.com/systemd/systemd/pull/24328#pullrequestreview-1074127504
We create the udevadm -> systemd-udevd symlink during the install phase,
so it doesn't exist in the just compiled tree. This worked in CI since
the symlink is manually created there post-build.
Otherwise the get_testdata_dir() call fails if the source tree is under
/root (which is usually the case in CIs).
I got bitten by this after leaving the source tree under /root but moving the
$BUILD_DIR elsewhere. This used to work by accident, as load_testdata_env()
would try to read $BUILD_DIR/systemd-runtest.env, but would fail if the
$BUILD_DIR is also under /root and fall back to SYSTEMD_TEST_DATA
(/lib/systemd/tests/testdata), which usually exist as we install the just built
revision. However, if the $BUILD_DIR is outside of /root we'd read
$BUILD_DIR/systemd-runtest.env which contains
SYSTEMD_TEST_DATA=/path/to/source/tree/test and that source tree is not visible
once we overmount /root with tmpfs making the test fail:
/* test_run_tests_unprivileged */
Successfully forked off '(test-execute-unprivileged)' as PID 10672.
Changing mount flags / (MS_REMOUNT|MS_BIND "")...
Changing mount propagation / (MS_REC|MS_SHARED "")
Mounting tmpfs (tmpfs) on /dev/shm (MS_NOSUID|MS_NODEV "")...
Mounting tmpfs (tmpfs) on /root (MS_NOSUID|MS_NODEV "")...
Mounting tmpfs (tmpfs) on /tmp (MS_NOSUID|MS_NODEV "")...
Mounting tmpfs (tmpfs) on /var/tmp (MS_NOSUID|MS_NODEV "")...
Mounting tmpfs (tmpfs) on /var/lib (MS_NOSUID|MS_NODEV "")...
Mounting tmpfs (tmpfs) on /run/test-execute-unit-dir (MS_NOSUID|MS_NODEV "")...
ERROR: $SYSTEMD_TEST_DATA directory [/root/systemd/test] not accessible: No such file or directory
Assertion 'get_testdata_dir("test-execute/", &unit_dir) >= 0' failed at src/test/test-execute.c:1306, function prepare_ns(). Aborting.
(test-execute-unprivileged) terminated by signal ABRT.
So the multiple-machines tests run last to avoid a race where the
checked signal would get ignored while the stub init is still processing
the previous signals:
[ 17.380417] testsuite-13.sh[376]: + machinectl reboot long-running long-running long-running
[ 17.389888] systemd-nspawn[495]: ++ touch /reboot
[ 17.390904] testsuite-13.sh[376]: + rm -f /var/lib/machines/long-running/trap
[ 17.393937] testsuite-13.sh[376]: + machinectl kill --signal=SIGTRAP --kill-whom=leader long-running
[ 17.408905] testsuite-13.sh[376]: + timeout 10 bash -c 'while ! test -e /var/lib/machines/long-running/trap; do sleep .5; done'
[ 27.413210] testsuite-13.sh[376]: + at_exit
...
[ 27.993376] testsuite-13.sh[373]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/testsuite-13.machinectl.sh failed'
Introduce a manual test tool that creates a journal, corrupts it by
flipping bits at given offsets, and then attempts to write to the journal.
In ideal case we should handle this gracefully without any crash or
memory corruption.
When reexecuting system let's put our arguments carrying deserialization
info first followed by any existing arguments to make sure they get
parsed in case we get weird stuff from the kernel cmdline (like --).
See: https://github.com/systemd/systemd/issues/28184
So we're able to detect memory leaks in our NSS modules.
An example after introducing a memory leak in nss-myhostname.c:
testsuite-71.sh[2881]: =================================================================
testsuite-71.sh[2881]: ==2880==ERROR: LeakSanitizer: detected memory leaks
testsuite-71.sh[2881]: Direct leak of 2 byte(s) in 1 object(s) allocated from:
testsuite-71.sh[2881]: #0 0x7fa28907243b in strdup (/usr/lib64/libasan.so.8.0.0+0x7243b)
testsuite-71.sh[2881]: #1 0x7fa286a7bc10 in gethostname_full ../src/basic/hostname-util.c:67
testsuite-71.sh[2881]: #2 0x7fa286a74af9 in gethostname_malloc ../src/basic/hostname-util.h:24
testsuite-71.sh[2881]: #3 0x7fa286a756f4 in _nss_myhostname_gethostbyname4_r ../src/nss-myhostname/nss-myhostname.c:79
testsuite-71.sh[2881]: #4 0x7fa288f17588 in getaddrinfo (/lib64/libc.so.6+0xf4588)
testsuite-71.sh[2881]: #5 0x7fa2890a4d93 in __interceptor_getaddrinfo.part.0 (/usr/lib64/libasan.so.8.0.0+0xa4d93)
testsuite-71.sh[2881]: #6 0x55a54b2b7159 in ahosts_keys_int.part.0 (/usr/bin/getent.orig+0x4159)
testsuite-71.sh[2881]: SUMMARY: AddressSanitizer: 2 byte(s) leaked in 1 allocation(s).
As hitting an ASan/UBSan error in PID1 results in a crash (and a kernel
panic when running under qemu), we usually lose the stack trace which
makes debugging quite painful. Let's mitigate this by forwarding the
stack trace to multiple places - namely to a file and the syslog.
To suppress a warning on journal-remote startup:
systemd-journal-remote[691]: microhttpd:
MHD_OPTION_EXTERNAL_LOGGER is not the first option specified for
the daemon. Some messages may be printed by the standard MHD
logger.
Frantisek Sumsal