Dmitry V. Levin [Fri, 10 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udev_rules_parse_file: issue diagnostics about duplicate LABEL tokens
When a rules contains several LABEL tokens, the parser used to silently
discard all of them besides the last one without any diagnostics at all.
It's time to break the vow of silence and let the parser issue a warning.
Dmitry V. Levin [Thu, 9 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udevadm verify: introduce --root option
When udevadm verify is invoked without positional arguments and loads
all rules files from the system like the udev daemon does, this option
can be used to operate on files underneath the specified root path.
Dmitry V. Levin [Thu, 9 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udevadm verify: load all rules from the system if no rules were given
When udevadm verify is invoked without positional arguments, that is,
when no udev rules files are specified, load all rules files from the system
like the udev daemon does, and verify them.
Will Fancher [Wed, 8 Feb 2023 03:00:38 +0000 (22:00 -0500)]
mount: Include After=local-fs-pre.target by default in initrd
Although it may be true that /sysroot and its children don't belong in
local-fs.target, that doesn't mean they shouldn't come after
local-fs-pre.target. For instance, systemd-hibernate-resume@.service needs to
come before /sysroot and its children, but currently that only happens
coincidentally because of the ordering between systemd-fsck@.service and
local-fs-pre.target. As a result, mount units can be mistakenly started
simultaneously with systemd-hibernate-resume@.service, which can cause
corruption and data loss in the worst of cases.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
Ronan Pigott [Tue, 28 Feb 2023 05:57:06 +0000 (22:57 -0700)]
load-fragment: add user credential specifiers to user.conf
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.
mempress: change default PSI window duration to 2s
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.
dissect-image: set MS_NOSYMFOLLOW for ESP/XBOOTLDR
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:
dissect: allow setting "lo_file_name" field of loopback block devices
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.
dissect: add commands for attaching/detaching loopback devices
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.
test: fall back to /sys/fs/cgroup/systemd if necessary
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.
test: force mkfs.btrfs to overwrite any existing file systems
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.
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 (f58269510727964cb5c10e7d2f9849c442ea1f80).
This breaks the assumption that if --lines is set,
the boundary is never exceeded because the counter of
outputs gets us covered.
tests: merge test-tmpfiles.c into test-tmpfile-util.c
The former was added in 65b3903ff576488eaabb51d3c4fbf9c73d867d7c,
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.
test: don't fail if we can't remove the scsi_debug module
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
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.
Yu Watanabe [Thu, 9 Mar 2023 04:05:57 +0000 (13:05 +0900)]
Merge pull request #26698 from ldv-alt/udevadm-verify
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.
> 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?
Dmitry V. Levin [Wed, 8 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udev_rules_parse_file: issue diagnostics about line continuation at EOF
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.
Dmitry V. Levin [Fri, 3 Mar 2023 08:00:00 +0000 (08:00 +0000)]
meson.build: check udev rules using udevadm verify
Although udev rules are already being checked by rule-syntax-check.py
script, also check them using udevadm verify which performs more
thorough checks.
Dmitry V. Levin [Thu, 2 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udevadm: introduce new 'verify' command
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.
Dmitry V. Levin [Wed, 1 Mar 2023 08:00:00 +0000 (08:00 +0000)]
udev_rules_parse_file: mark logged issues
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.
Luca Boccassi [Wed, 8 Mar 2023 12:59:40 +0000 (12:59 +0000)]
core: log message when reloading finishes
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.