These are only used in the importd binary, which is a leaf optional
binary that also depends on libcurl, so it's not worth the
additional complications
For example with SetCredential=mycred: the data payload is empty, but it
is still a valid credential.
This reorders the arguments when serializing credentials, so the
possibly empty argument is not at the end of the serialized string. This
way we can still easily use the extract_many_words() machinery, and with
the use of EXTRACT_DONT_COALESCE_SEPARATORS properly deserialize even an
empty credential. This changes LoadCredentials= as well just to keep the
code for (de)serializing both directives in sync.
With plain QEMU on a saturated AWS region we might just barely miss the
timeout window, causing unexpected test fails:
[ 688.681324] systemd-nspawn[1332]: [ OK ] Finished systemd-user-sessions.service.
[ 689.451267] systemd-nspawn[1332]: [ OK ] Started console-getty.service.
[ 689.572874] systemd-nspawn[1332]: [ OK ] Reached target getty.target.
[ 693.634609] testsuite-74.sh[1223]: + at_exit
[ 693.634609] testsuite-74.sh[1223]: + rm -fv -- /tmp/test-dump /tmp/test-usr-dump /tmp/make-dump
[ 693.838395] testsuite-74.sh[1502]: removed '/tmp/test-dump'
[ 693.838395] testsuite-74.sh[1502]: removed '/tmp/test-usr-dump'
[ 693.838395] testsuite-74.sh[1502]: removed '/tmp/make-dump'
[ 693.951114] testsuite-74.sh[670]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/testsuite-74.coredump.sh failed'
[ 693.951114] testsuite-74.sh[670]: Subtest /usr/lib/systemd/tests/testdata/units/testsuite-74.coredump.sh failed
[ 693.951114] testsuite-74.sh[670]: + return 1
[ 694.659094] systemd[1]: testsuite-74.service: Main process exited, code=exited, status=1/FAILURE
[ 694.719563] systemd[1]: testsuite-74.service: Failed with result 'exit-code'.
[ 694.882069] systemd[1]: Failed to start testsuite-74.service.
[ 695.574445] systemd[1]: Reached target testsuite.target.
[ 696.174844] systemd[1]: Starting end.service...
[ 699.509408] systemd-nspawn[1332]:
[ 699.509408] systemd-nspawn[1332]: CentOS Stream 9
[ 699.509408] systemd-nspawn[1332]: Kernel 5.14.0-432.el9.x86_64 on an x86_64 (pts/0)
[ 699.509408] systemd-nspawn[1332]:
Also, move the rest of container the setup for the user xattrs test into
the condition, since doing it without the actual test is pretty
pointless.
The SHA for this action was updated by Dependabot in #25900 to a commit
which later disappeared from the repo. Since then Dependabot kept
(silently) failing to bump the SHA further:
updater | 2024/03/31 21:22:13 ERROR <job_807574419> Error processing stefanbuck/github-issue-parser (Dependabot::SharedHelpers::HelperSubprocessFailed)
updater | 2024/03/31 21:22:13 ERROR <job_807574419> error: no such commit c1a559d78bfb8dd05216dab9ffd2b91082ff5324
See: https://github.com/systemd/systemd/pull/25900#issuecomment-2028912672
Let's bump the SHA manually to v3.1.0 to get Dependabot back on the track.
Co-authored-by: Evgeny Vereshchagin <evvers@ya.ru>
We are saying in public that the protocl is stable and can be easily
reimplemented, so provide an example doing so in the documentation,
license as MIT-0 so that it can be copied and pasted at will.
The debian revision starts after the '-' character, so make sure the
timestamp we append is treated as the revision instead of being a part
of the upstream version.
Currently, if unmount initiated by us fails, we record
that in result. Later, if we tried again and succeeded,
or someone else successfully unmounted it, the unit
state is still considered failed. Let's be more tolerant
instead, and forget about previous failure.
Alternative to #32002
The MatchPattern= in Target specification is documented as mandatory,
but if not defined sysupdate will assume the same value as definied
in Source specification and continue execution. Print this
assumptions to the user
Previously, it was impossible to freeze or thaw a slice if it is an
ancestor to a unit that had no running cgroup (i.e. a service with
RemainAfterExit=yes). Instead of failing with EBUSY (which would
confusingly get reported as "Unit has pending job") we just silently
no-op.
I noticed this because we now have user-runtime-dir@.service, which
would make it impossible to freeze/thaw user.slice or user-<UID>.slice
Same reason as the reload, reexec is disruptive and it requires the
same privileges, so if somebody wants to limit reloads, they'll also
want to limit reexecs, so use the same setting.
Previously, 'udevadm test' performs not only processing udev rules,
but made several destructive change on the system; updating udev
database, device node permission, devlinks, network interface
properties, and so on.
Similary, 'udevadm test-builtin' may perform something destructive,
especially by 'keyboard', 'kmod', and 'net_setup_link' builtins.
Let's make these commands and test executables not change device
configurations.
