It's been there since the test was introduced and I'm not really sure
what was the original intention behind it, but it makes systemd sad:
[ 4.909056] systemd[1]: /usr/lib/systemd/tests/testdata/units/testsuite-44.service:13: Unknown key name 'LogTarget' in section 'Service', ignoring.
Otherwise we get a not very nice message when trying to display a
non-existent man page:
~# systemctl cat test.service
[Unit]
Description=Hello
[Service]
ExecStart=true
~# systemctl help test.service
Documentation for (null) not known.
Since we parse it on the other side via parse_percent() which requires
that, otherwise we get an error:
[ 8.133131] testsuite-13.sh[649]: + machinectl import-raw /tmp/container.raw container-raw
[ 8.175035] machinectl[1143]: Enqueued transfer job 1. Press C-c to continue download in background.
[ 8.182130] machinectl[1143]: Importing '/tmp/container.raw', saving as 'container-raw'.
[ 8.182377] systemd-importd[1144]: Got invalid percent value '0', ignoring.
[ 8.182451] machinectl[1143]: Imported 0%.
[ 8.282669] systemd-importd[1144]: Got invalid percent value '40', ignoring.
[ 8.282746] machinectl[1143]: Imported 40%.
[ 8.366448] machinectl[1143]: Wrote 64.0M.
[ 8.366519] machinectl[1143]: Operation completed successfully.
[ 8.366617] machinectl[1143]: Exiting.
The unit will be started or restarted a few times during boot, but but it has
StartLimitBurst = DefaultStartLimitBurst = 5, which means that the fifth
restart will already fail. On my laptop, I have exactly 4 restarts, so I don't
hit the limit, but on a slightly different system we will easily hit the limit.
In https://bugzilla.redhat.com/show_bug.cgi?id=2251394, there are five reloads
and we hit the limit.
Since 6ef512c0bb we propagate the start counter
over switch-root and daemon reloads, so it's easier to hit the limit during
boot.
In principle there might be systems with lots of vtcon devices, so let's just
allow the unit to be restarted without a limit.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2251394.
This reverts commit 30462563b1.
fchmodat2(), while accepting AT_SYMLINK_NOFOLLOW as a valid flag,
always returns EOPNOTSUPP when operating on a symlink. The Linux kernel
simply doesn't support changing the mode of a symlink.
Fixes#30157
when KERNEL_INSTALL_UKIFY is not supplied we set ukify to $PWD/ukify
that will fail (perhaps only for manual installations):
FileNotFoundError: [Errno 2] No such file or directory: '/usr/src/linux-6.7-rc1/ukify'
this will make sure we have a sane default for UKIFY
Signed-off-by: Paymon MARANDI <paymon@utubeipod.xyz>
The command arguments may contain spurious characters, e.g. line-break.
When we use command arguments as a description of a unit, we should
escape them.
Fixes#30187.
Turns out that redirecting a lot of output to the console can have some
funny effects, like random kernel soft lockups. I spotted this in
various CIs, but it remained almost entirely hidden thanks to
`softlockup_panic=1`, until 1a36d2672f which introduced a couple of
tests that log quite a lot in a short amount of time. This, in
combination with newer kernel version, which, for some reason, seem to
be more susceptible to such soft lockups, made the Arch Linux jobs soft
lockup quite a lot, see [0].
While debugging this I also noticed that runs which don't redirect
stdout/stderr to the console are noticeably faster, e.g.:
# TEST-71 nspawn + QEMU (KVM), StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:24.64
# TEST-71 nspawn + QEMU (KVM), StandardOutput=journal
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:17.95
# TEST-71 nspawn + QEMU, StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:04.70
# TEST-71 nspawn + QEMU, StandardOutput=journal
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:44.48
# TEST-04 QEMU, StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:22.70
# TEST-04 QEMU, StandardOutput=console
Elapsed (wall clock) time (h:mm:ss or m:ss): 5:04.67
Given all this, let's effectively revert ba7abf79a5, and dump the
testsuite-related journal messages only after the test finishes, so they
don't go through the slow console.
Resolves: systemd/systemd-centos-ci#660
[0] https://github.com/systemd/systemd-centos-ci/issues/660
MemoryCurrent and MemoryAvailable are shown as "[not set]" when UINT64_MAX
(unset). Let's do the same for the newly-added Memory*{Current,Peak} properties.
Let's put the section name at the beginning of each sentence. This way we
can avoid awkward constructs like "kernel is looked for in the .linux section".
Also, since the paragraph above says that this is a list of "PE sections", we
can just say "section". In other places, it is often useful to say "PE section"
to avoid ambiguity.
Also fix the off-by-one in the count of sections.