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
- introduce device_should_have_db(),
- split out device_get_db_path(),
- update log messages, especially clarify which stage is failed,
- use _cleanup_(unlink_and_freep) attribute,
- clear existing database file also when failed to create database directory
and when failed to create temporary file.