IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's allow configuring tty term and size using kernel cmdline arguments
so that when running in a VM we can communicate the terminal TERM and size
from the host via SMBIOS extra kernel cmdline arguments.
Those are rather specialized bits of information, useful mostly for debugging.
I use cgls quite often but never had the need to use either of those…
But they take up a significant amount of screen real estate, esp. when
executed as root:
-.slice
├─user.slice (#1683)
│ → user.invocation_id: 74b0bd1258c5485eb969016384e0d06a
│ → trusted.invocation_id: 74b0bd1258c5485eb969016384e0d06a
│ └─user-1000.slice (#6488)
│ → user.invocation_id: b0261a14fe74490d9a9d5266c52cceb6
│ → trusted.invocation_id: b0261a14fe74490d9a9d5266c52cceb6
│ ├─user@1000.service … (#6590)
│ │ → user.invocation_id: 9e1fb54ad07940d8b92c33c81d169f11
│ │ → user.delegate: 1
│ │ → trusted.invocation_id: 9e1fb54ad07940d8b92c33c81d169f11
│ │ → trusted.delegate: 1
│ │ ├─session.slice (#6874)
...
Let's not show them by default, so we can show more cgroups.
(Also, on a terminal, we already highlight delegate units via underlining and
an ellipsis, so 'user.delegate:1' is redundant.)
This ensure messages from PID1 regarding a unit also contain those
fields. For example, portable services have PORTABLE=<image> as
extra fields, which is useful to identify which version of a portable
image produced a log message like an error or an oomd kill.
On some ARM platforms, the dynamic linker could use PROT_BTI memory protection
flag with `mprotect(..., PROT_BTI | PROT_EXEC)` to enable additional memory
protection for executable pages. But `MemoryDenyWriteExecute=yes` blocks this
with seccomp filter denying all `mprotect(..., x | PROT_EXEC)`.
Newly preferred method is to use prctl(PR_SET_MDWE) on supported kernels. Then
in-kernel implementation can allow PROT_BTI as necessary, without weakening
MDWE. In-kernel version may also be extended to more sophisticated protections
in the future.
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.
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.
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
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.
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
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
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
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().
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.
Detect image type using "bootctl kernel-identify $kernel",
store result in KERNEL_INSTALL_IMAGE_TYPE.
Extend layout autodetection to check the kernel image type
and pick layout=uki for UKIs.
Resolves: #25822
