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.
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.
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.
See #26688: getenv() is not thread-safe, and could a possible source of
problems when a multi-threaded program calls setenv()/putenv()/unsetenv() in
parallel. It is not possible to avoid getenv() calls in general, since $PATH,
$LANG, $SHELL, $USER, $HOME, $TZ may need to be accessed at any time.
Add a warning to our docs so that people are aware of the issue.
Closes#26688. (Real fixes will need to be in glibc and gnome-shell or other
programs.)
The text is added to threads-aware.xml to be included in various places. By
including it in libsystemd-pkgconfig.xml, it is automatically added to all sd-*
pages. The text is also included explicitly in pages for a few other functions
which are call getenv().
This commit fixes an issue where systemd-timesyncd re-synchronizes the
system clock every time the network configuration is updated, no matter
whether link servers are actually changed.
Fixes a bug introduced by e05dd7718d.
When compliled without libxkbcommon, we do no verification and accept the
arguments as given. When compliled against with, if dlopen() works, we do the
verification. But if dlopen() fails, we would refuse the call and return
SD_BUS_ERROR_INVALID_ARGS. 5de344704d added things
this way when converting to dlopen(), but it seems not very useful: it can be
expected that when the library is supported but missing at runtime, we degrade
softly, and that the behaviour is something inbetween the cases of hard disable
at compilation time and full support. But right now we behave more strictly then
if disabled at compilation. Change the code to just warn if dlopen fails, but
accept the arguments.
(There are various minimization scenarios where forcing the installation of
libxkbcommon is not useful. E.g. a small installation where we want to set the
keymap via logind, but the configuration is managed by a configuration
management system and is known to be valid. Verification via libxkbcommon is
just overhead in this case.)
800f65f827 moved the check earlier, so now even
a noop case of setting the values that were already in place can fail.
C.f. https://bugzilla.redhat.com/show_bug.cgi?id=2175244.
For any user on a semi-recent kernel, effectively this setting is pointless.
We should deprecate it once not needed anymore for the v1 hierarchy. For
now, adjust the description.
When cpu controller is disabled, thing would often still behave as if
it was. And since the cpu controller can be enabled "magically" e.g. by
starting user@1000, add a note for users to be careful. Autogrouping
is described well in the man page, incl. how to enable or disable it,
so it should be enough to refer to that.
For CPUWeight=: there is an important distinction between our default of
[not set], and the kernel default of "100". Let's not say that our default
is "100" because then 'systemctl show' output is hard to explain.
For task accounting, it's the kernel that does the accounting, not systemd.
For a user, information which cgroup controllers are enabled based on
the unit configuration is rather important. Not only because it determines
what resource control is peformed by the kernel, but also because controllers
have a non-negligible cost, especially for deep nesting, and users may want
to *not* have controllers enabled.
Our documentation did its best to avoid the topic so far. This was partially
caused by the support for cgroup v1, which meant that any discussion of
controllers had to be conditional and messy. But v1 is deprecated on its way
out, so it should be fine to just describe what happens with v2.
The text is extended with a discussion of how controllers are enabled and
disabled, and an example, and for various settings that enable controllers
the relevant controller is now mentioned.
The details discussion of how search and route-only domains work is in
systemd-resolved.service(8). But users are more likely to look at
resolved.conf(5), because that's where Domains= is described. So let's add a
reference to the other man page there, and also strengthen the text a bit. In
particular, in systemd-resolved.service(8) we say "route-only", which makes
the distinction with search domains clearer. Let's use the same in the other
man page too.
This is based on feedback from Lukáš Nykrýn that the man page is not clear
enough.
Lennart Poettering
Jeidnx
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Yu Watanabe
Luca Boccassi
Dmitry V. Levin
Frantisek Sumsal
Chitoku
Daan De Meyer