Previously, if journal_file_set_offline() is called twice with 'wait = false',
the second call triggered segfaults, as the offline_state is OFFLINE_DONE,
and journal_file_set_offline_thread_join() tries to call pthread_join()
with NULL.
Currently some of the code base check for the variable presence before
removing it, and some do not.
More so, in all cases (being updated) we're dealing with non-volatile
variables where changing those attribute to NVRAM wear out.
From what information I could find, there is no definitive answer if the
UEFI implementation will write to the NVRAM even when the variable is
missing.
So add a simple helper that checks for the variable presence before
removing it. While also having a bit cleaner API than the current
efivar_set(..., NULL, ...);
efivar_unset() follows the design from efivar_set*() where it returns an
EFI_STATUS even though its (presently) unused.
v2:
- add inline comment, use early return
v3:
- typos? typos!
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This helps a lot with figuring out why units were started when they
were, rather than guessing there is a dependency relation. We could
perhaps also do fun JavaScript things in the future to highlight
dependencies on mouse-over.
This reverts the following commits.
- a1640191b4
- 231741d355
These were done by my misunderstanding of the mmap cache behavior.
Also, this updates the comments added by
df04b9ed86.
note that this slightly changes the semantic of assert when NDEBUG is
defined. if there's an extern function call (without attribute pure or
similar) then the compiler has to assume it has side effects and still
emit the function call.
whereas the old assert guaranteed that nothing will be evaluated on
NDEBUG.
Closes: https://github.com/systemd/systemd/issues/29408
This matches the change to tpm2_seal(), which now accepts a Tpm2Context instead
of a device string.
This also allows using the same TPM context for sealing and unsealing, which
will be required by (future) test code when sealing/unsealing using a transient
key.
Simplify the function with GREEDY_REALLOC_APPEND(). Also limit the size_t-sized
max value to UINT32_MAX since that's the maximum of the range this searches,
and the max parameter for tpm2_get_capability() is uint32_t.
The test expects TPM2_CC_FIRST - 1 and TPM2_CC_LAST + 1 to be unsupported, but
those are not necessarily invalid commands. Instead test known-invalid
commands. Also add some more valid commands.
Because most TPM2 functions here are 'library-like' functions, they should be
at debug level, not error level.
The only functions not reduced to logging at debug are tpm2_list_devices(),
since it is expected to print output, and the tpm2_parse_pcr_argument_*()
functions, since the system-wide parse_*_argument() functions generally log at
error level.
Otherwise they might leave stuff behind if they don't respond fast
enough to the first SIGTERM and get SIGKILLEd, which then breaks reusing
the unit name further in the test:
[ 2993.620849] H testsuite-82.sh[43]: + systemd-run -p Type=exec -p DefaultDependencies=no -p IgnoreOnIsolate=yes --unit=testsuite-82-nosurvive.service sleep infinity
[ 2993.628686] H systemd[1]: testsuite-82-nosurvive.service: About to execute: /usr/bin/sleep infinity
[ 2993.628886] H systemd[1]: testsuite-82-nosurvive.service: Forked /usr/bin/sleep as 65
[ 2993.629328] H systemd[1]: testsuite-82-nosurvive.service: Changed dead -> start
...
[ 2993.699892] H testsuite-82.sh[43]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[ 2993.704326] H systemd-logind[41]: The system will soft-reboot now!
...
[ 3001.249302] H systemd[1]: Sending SIGKILL to PID 65 (sleep).
...
[ 3001.303158] H testsuite-82.sh[136]: + systemd-notify '--status=Second Boot'
...
[ 3001.409504] H testsuite-82.sh[136]: + systemd-run -p Type=exec --unit=testsuite-82-nosurvive.service sleep infinity
[ 3001.414061] H testsuite-82.sh[165]: Failed to start transient service unit: Unit testsuite-82-nosurvive.service was already loaded or has a fragment file.
Spotted in Ubuntu CI.
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.
The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.
Fixes https://github.com/systemd/systemd/issues/22177
Fixes https://github.com/systemd/systemd/issues/20617
Fixes https://github.com/systemd/systemd/issues/19118