This enables the ManagerEnvironment= settings in the user's user.conf to
reference some user data like $HOME for the purpose of setting
environment variables derived from these values.
This changes the PSI window duration we default to for watching memory
pressure events from 1s to 2s. This is because apparently the kernel
will soon disallow window durations other than 2s for unprivileged
processes.
Hence, we'll bump the threshold from 100m to 200ms, and the window from
1s to 2s.
This way we'll have the same mount options in place if we boot via the
gpt generator, or if we mount a DDI locally.
Note that this will also enable MS_NOSYMFOLLOW on ESP and XBOOTLDR now,
if booted via gpt-auto-generator.
When we mount a DDI, let's set MS_NOSYMFOLLOW for ESP/XBOOTLDR. They are
generally untrusted territory, (i.e. outside of
encryption/authentication via dm-crypt/dm-verity). Moreover they are
generally FAT, where symlinks don't exist anyway. Let's hence disable
symlinks for them.
This slightly refactors how we put together mount options for mounts,
splitting this out into a new helper call
dissected_partition_pick_options(), which we should be able to reuse
later in gpt-auto-generator, to ensure mounts via loopback as DDI and
those on bare metal get the same options.
Necessary for some CI setups where we boot an nspawn container on a host
with older systemd with legacy hierarchy, so systemd mounts its stuff
under /sys/fs/cgroup/systemd.
mkfs.btrfs (unlike mkfs.ext4) checks if the target already contains
a file system and refuses to continue if so. This causes spurious fails
in case the random garbage on the temporary device matches a valid FS
header:
[ 19.723806] testsuite-64.sh[355]: + udevadm lock --device=/dev/mapper/encbtrfs0 --device=/dev/mapper/encbtrfs1 --device=/dev/mapper/encbtrfs2 --device=/dev/mapper/encbtrfs3 mkfs.btrfs -M -d raid1 -m raid1 -L btrfs_mencdisk -U deadbeef-dead-dead-beef-000000000003 /dev/mapper/encbtrfs0 /dev/mapper/encbtrfs1 /dev/mapper/encbtrfs2 /dev/mapper/encbtrfs3
[ 19.918934] testsuite-64.sh[2494]: ERROR: /dev/mapper/encbtrfs0 appears to contain an existing filesystem (hfsplus)
[ 19.920490] testsuite-64.sh[2494]: ERROR: use the -f option to force overwrite of /dev/mapper/encbtrfs0
Let's force mkfs.btrfs to overwrite the file system in such case.
After Delegate= was converted from boolean to a controller list, the dump
output was changed to have a separate line about the delegated controllers:
...
DevicePolicy: auto
DisableControllers:
Delegate: yes
ManagedOOMSwap: auto
ManagedOOMMemoryPressure: auto
ManagedOOMMemoryPressureLimit: 0.00%
ManagedOOMPreference: none
DelegateControllers: cpu memory pids
...
The line with "Delegate:" is redundant, it effectively shows if
"DelegateControllers:" is non-empty. It is nicer to keep the lines
about controllers adjacent. And to avoid duplicate output, Delegate:
will now show which controllers are enabled. This makes the output
for that line again match the configuration stanza Delegate=:
DisableControllers:
Delegate: cpu io memory pids
ManagedOOMSwap: auto
ManagedOOMMemoryPressure: auto
ManagedOOMMemoryPressureLimit: 0.00%
ManagedOOMPreference: none
MemoryPressureWatch: auto
MemoryPressureThresholdSec: 100ms
Dump output is for debugging, we don't need to maintain strict
backwards-compat.
This is a follow-up for #26669 (81fb5375b3).
After the mentioned commit, we stopped checking if the
entry is within the range of --until if --lines is used.
However, when --since, --until and --lines=N are used
altogether, and the number of lines between --since
and --until is smaller than N, we would seek to --since
later (f582695107).
This breaks the assumption that if --lines is set,
the boundary is never exceeded because the counter of
outputs gets us covered.
The former was added in 65b3903ff5,
but the name is confusing: the test has nothing to do with systemd-tmpfiles.
It had one function that mostly tested functions from tmpfile-util.c, so
just move it into the latter.
Let's make the cleanup 'best effort' operation, as sometimes we might
not be able to remove the scsi_debug module, and we don't really care
if it stays loaded:
[ 88.521333] testsuite-17.sh[1827]: ID_TEST=test
[ 88.522015] testsuite-17.sh[1679]: + rmmod scsi_debug
[ 88.524795] testsuite-17.sh[1828]: rmmod: ERROR: Module scsi_debug is in use
[ 88.527786] testsuite-17.sh[1679]: + cleanup_17_10
Let's attempt to reduce the amount of flakes further when the AWS region
we run in is under heavy load and the hypervisor stars stealing our CPU
time.
Follow-up to e0cbb73911 and c78d18215b.
As the test runs during machine bootup where jobs run in parallel,
busctl might attempt to introspect a job that already finished and fail.
Since in this case we're more interested in crashes/leaks, let's ignore
the exit code.
Follow-up to 16600a8661.
Implement a udev rules syntax checker in the form of
`udevadm verify [OPTIONS] FILE...` command that is based on
`udev_rules_parse_file` interface and would apply further checks
on top of it in the future.
Resolves: #26606
Follow-up for 82c2095a5e.
> I feel like the logging here may be a bit confusing on the new path.
> Previously you did get a message that explained what was going on. Now you get
> an info message that the layout could not be compiled, and … that's all. I can
> imagine this being a confusing red herring if someone was trying to debug a
> problem and saw this message. Perhaps we should log something else instead/as
> well, on the case where libxkbcommon isn't present, to say that's what we're
> logging about and it just means we can't validate the configuration, not that
> it's definitely invalid?
When udev rules file ends with a line continuation, the parser
used to silently ignore the line without any diagnostics at all.
It's time to break the vow of silence and let the parser issue some
error diagnostics.
Although udev rules are already being checked by rule-syntax-check.py
script, also check them using udevadm verify which performs more
thorough checks.
When built without blkid, then udev-builtin-blkid is not built,
and the verifier warns about the unknown builtin:
60-persistent-storage.rules:114 Unknown builtin command: blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}
60-persistent-storage.rules:117 Unknown builtin command: blkid --noraid
60-persistent-storage.rules:120 Unknown builtin command: blkid
60-persistent-storage.rules: udev rules check failed
We seem to have no tool to verify udev rule files. There is a simple
udev rules syntax checker in the tree, test/rule-syntax-check.py, but
it is too simple to detect less trivial issues not detected by udev,
e.g. redundant comparisons (#26593) or labels without references.
Such a tool would be beneficial not only for maintaining udev rules
distributed along with udev, but also and even more so for maintaining
third party udev rules that are more likely to have issues with syntax
and semantic correctness.
Implement a udev rules syntax and semantics checker in the form of
'udevadm verify [OPTIONS] FILE...' command that is based on
udev_rules_parse_file() interface and would apply further checks
on top of it in subsequent commits.
Resolves: #26606
Traditionally, all issues found in udev rules by udev_rules_parse_file()
are logged and ignored, so there was no mechanism to propagate the
information about these issues back to the caller.
Introduce such a mechanism by adding a new member to UdevRuleFile.
This new member is a bitmask describing which log levels were used
in messages logged with regards to the rule file.
This mechanism is going to be used by udevadm verify in subsequent
commits.
Reloading might be slow, especially when under memory pressure, and watchdogs
might be triggered. It is useful to have timestamped telemetry in the journal
to see how long a reload takes.
Lennart Poettering
Daan De Meyer
Ronan Pigott
Luca Boccassi
Yu Watanabe
Frantisek Sumsal
Jeidnx
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Dmitry V. Levin