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.
This adds symlinks that allow accessing loopback block devices via stable
names that reference their backing block devices, make the unpredictable
naming of loopback devices less of an issue.
Example:
1. Create a loopback block device for a file $F
losetup --find $F
2. Reference the backing block device via its inode:
L="$(stat -c '/dev/loop/by-inode/%Hd:%Ld-%i' $F)"
fdisk $L
In the above the loop device name (which might be /dev/loop47 or any
other name) is not used at all.
When attaching a loopback file this allows us to set an explicit name
for it. This is useful since it allows a caller to pre-select a string
that is directly attached to the loopback file. Via udev rules we'l
later make the device accessible through this name.
Note that "lo_file_name" is supposed to carry a file name of the backing
file, but the kernel actually does not care or enforce any of that, it
just stores the filename and returns it later. This makes it so useful,
as userspace has total control of that field.
"lo_file_name" should not be confused with the sysattr
"loop/backing_file" which is actually maintained by the kernel itself,
and always shows the file to the backing inode without userspace having
direct control over the returned string. Because the sysattr is
generated by the kernel it is subject to file system namespacing and
everything, while "lo_file_name" is not, it's really just a string
passed through the kernel.
Sometimes it is useful attaching DDIs without mounting them. We could
use "losetup" for that, but doing this in systemd-dissect has various
benefits:
1. we superficially validate the DDI first
2. we set the sector size depending on what we determine
3. we synchronously create the per-partition block devices
This adds support for retrieving info about the inode backing a loopback
file to udev-builtin-blkid. It will pick up the inode number and device
of the backing inode, as well as the lo_file_name[] array that the
loopback device maintains.
A later patch uses this information to create block device symlinks in
/dev/ that allow refering block devices by their backing inodes. This is
useful when separate tools set up a loopback device from those which
ultimately shall mount them, and there shall be a stable reference be
passed along. For example, we can add a new kernel option setuploop= or
so which allows setting up a block device via a generator, and still
have a way to safely reference later.
And yes, this doesn't directly have anything to do with the probing
libblkid does, but it's close enough, and we have the device open anyway
here, so the additional ioctl() here should not hurt.
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?
Lennart Poettering
Daan De Meyer
Ronan Pigott
Luca Boccassi
Yu Watanabe
Frantisek Sumsal
Jeidnx
Zbigniew Jędrzejewski-Szmek
Mike Yuan