Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip
over an assertion:
[ 132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[ 132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice.
[ 133.018292] H systemd[1]: Starting inhibit.service...
[ 133.122610] H systemd[1]: Started systemd-coredump@0-665-0.service.
[ 133.163643] H systemd[1]: Started inhibit.service.
[ 133.206836] H testsuite-82.sh[614]: + exec sleep infinity
[ 133.236762] H systemd-logind[611]: The system will reboot now!
[ 135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core.
Stack trace of thread 663:
#0 0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf)
#1 0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5)
#2 0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6)
#3 0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5)
#4 0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6)
#5 0x000000000040e478 monitor (busctl + 0xe478)
#6 0x000000000040e82f verb_monitor (busctl + 0xe82f)
#7 0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb)
#8 0x00000000004074fa busctl_main (busctl + 0x74fa)
#9 0x0000000000407525 run (busctl + 0x7525)
#10 0x000000000040ff67 main (busctl + 0xff67)
#11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85)
#12 0x00000000004044be _start (busctl + 0x44be)
ELF object binary architecture: AMD x86-64
[ 136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed.
[ 136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT
[ 136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'.
The asertion in question:
Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting.
We can get a NULL message here through sd_bus_process() ->
bus_process_internal() -> process_running(), so let's handle this case
appropriately.
Since the triggered unit intentionally fails without consuming any data
from the socket, we'd try to trigger it again and again, and we might
try to check the unit state in one of the "in-between" states, failing
the test:
[ 165.271698] H testsuite-07.sh[1032]: + systemctl start badbin_assert.socket
[ 165.977637] H testsuite-07.sh[1032]: + socat - ABSTRACT-CONNECT:badbin_assert.socket
[ 165.983787] H systemd[1]: Cannot find unit for notify message of PID 1039, ignoring.
[ 166.817187] H testsuite-07.sh[1032]: + timeout 10 sh -c 'while systemctl is-active badbin_assert.service; do sleep .5; done'
[ 167.049218] H testsuite-07.sh[1065]: active
[ 167.146854] H systemd[1]: Listening on badbin_assert.socket.
[ 167.163473] H systemd[1]: badbin_assert.socket: Incoming traffic
[ 167.542626] H systemd[1]: Cannot find unit for notify message of PID 1065, ignoring.
[ 167.543437] H (badbin)[1062]: badbin_assert.service: Failed to execute /tmp/badbin: Exec format error
[ 167.548346] H systemd[1]: badbin_assert.service: Main process exited, code=exited, status=203/EXEC
[ 167.549482] H systemd[1]: badbin_assert.service: Failed with result 'exit-code'.
[ 167.561537] H systemd[1]: badbin_assert.socket: Incoming traffic
[ 167.933390] H systemd[1]: Started badbin_assert.service.
[ 167.950489] H (badbin)[1070]: badbin_assert.service: Failed to execute /tmp/badbin: Exec format error
[ 167.956318] H systemd[1]: badbin_assert.service: Main process exited, code=exited, status=203/EXEC
[ 167.957173] H systemd[1]: badbin_assert.service: Failed with result 'exit-code'.
[ 167.974609] H systemd[1]: badbin_assert.socket: Incoming traffic
[ 168.042838] H testsuite-07.sh[1072]: failed
[ 168.094431] H testsuite-07.sh[1075]: ++ systemctl show -P ExecMainStatus badbin_assert.service
[ 168.704022] H systemd[1]: Started badbin_assert.service.
[ 168.778680] H (badbin)[1074]: badbin_assert.service: Failed to execute /tmp/badbin: Exec format error
[ 168.826881] H systemd[1]: badbin_assert.service: Main process exited, code=exited, status=203/EXEC
[ 168.833825] H systemd[1]: badbin_assert.service: Failed with result 'exit-code'.
[ 168.923931] H testsuite-07.sh[1032]: + [[ 0 == 203 ]]
[ 168.951492] H systemd[1]: Cannot find unit for notify message of PID 1075, ignoring.
[ 168.999862] H testsuite-07.sh[615]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/testsuite-07.issue-30412.sh failed'
[ 168.999862] H testsuite-07.sh[615]: Subtest /usr/lib/systemd/tests/testdata/units/testsuite-07.issue-30412.sh failed
Follow-up for 1eeaa93de3 and 28a2d27650.
ukify (and all the tests, including the autogenerated check-version-ukify)
does not work unless pefile is available, so track it as a dependency
in meson to avoid unit test failures later
Triggering assert_return() should be a bug in general, and we should
really fix that. But, previously, it is hard to notice such bug, as
it was not critical.
This is for making CI or our testing environment fail if we unexpectedly
trigger assert_return(). So, hopefully we can easily find such bugs.
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.
This effectively reverts fa6f37c043 just for TEST-04, as we nuke the
journal repeatedly in this test which makes it particularly hard to
debug. Let's hope the issue behind fa6f37c043 won't bite us back in this
case.
Follow-up for: fa6f37c043
Reverts: 8f7c876bdc
This is no longer necessary, as the test for which this was introduced
in the first place has this handled explicitly (testsuite-04.journal.sh).
Follow-up to 9457dd8bae.
With OpenSSL 3.2.0+ this is necessary, otherwise the verification
of such CA certificate fails badly:
$ openssl s_client -CAfile /run/systemd/remote-pki/ca.crt -connect localhost:19532
...
Connecting to ::1
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C=CZ, L=Brno, O=Foo, OU=Bar, CN=Test CA
verify error:num=79:invalid CA certificate
verify return:1
depth=1 C=CZ, L=Brno, O=Foo, OU=Bar, CN=Test CA
verify error:num=26:unsuitable certificate purpose
verify return:1
...
---
SSL handshake has read 1566 bytes and written 409 bytes
Verification error: unsuitable certificate purpose
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 26 (unsuitable certificate purpose)
Which dropped some whitespaces in the output:
$ openssl version
OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 Nov 2023)
$ openssl x509 -in cert.pem -text -noout | grep Issuer
Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
$ openssl version
OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
$ openssl x509 -in cert.pem -text -noout | grep Issuer
Issuer: C = XX, L = Default City, O = Default Company Ltd
Making test-ukify unhappy:
> assert 'Issuer: CN = SecureBoot signing key on host' in out
E AssertionError: assert 'Issuer: CN = SecureBoot signing key on host' in '<...snip...>Issuer: CN=SecureBoot signing key on host archlinux2\n...'
The binaries are built and installed if HAVE_TPM2 is set, and ignore ENABLE_BOOTLOADER,
so do the same for the manpages.
For the sd-pcrlock case this also installs the manpage aliases for the units, which
are not installed with -Dbootloader=disabled, but there's no way to conditionalize
the aliases, so on balance it's better to have too much documentation rather than
too little.
Fixes https://github.com/systemd/systemd/issues/30588
