Let's avoid any ambiguities around paths, and make them absolute when
accepting them, like we do in most our tools now. This makes us
independent of the current working directory and allows us to change it
without issues or pass around the paths elsewhere if need be.
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.
Let image_install figures the binary paths out itself as not all distributions
ship the mkfs.* tools in the same location. For example openSUSE ships
mksquashfs in /usr/bin/.
This fixes the tablet buttons on the Thinkpad X200 Tablet.
My Lenovo ThinkPad X200 Tablet is called "ThinkPadX200T" instead of "ThinkPadX200Tablet":
```
$ cat /sys/devices/virtual/dmi/id/modalias
dmi:bvnLENOVO:bvr7WET71WW(3.21):bd11/29/2012:br3.33:efr1.6:svnLENOVO:pn7453WVK:pvrThinkPadX200T:rvnLENOVO:rn7453WVK:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:sku:
```
This patch makes both strings work correctly to support the extra tablet keys.
For nspawn and services we first turn off two-way propagation of mounts
from host to sandbox via MS_SLAVE, and then set MS_SHARED again, so that
we create a new mount prop peer group again, and that we provide
behaviour similar to what we provide on the host further down the tree.
Let's do the same in detach_mount_namespace(), which we use for the
temporary mounts in the implementation of --image= in various tools.
This doesn't fix any immediate issue, but ensures we expose somewhat
systematic behaviour: whenever we detach mount namespaces we always set
things back to MS_SLAVE in the child.
ExecContext has a field that controls the mount propagation flag of the
mounts in the resulting namespace. This is exposed as "MountFlags="
which is super confusing, as it suggests one could control more than
propagation, and that it was actually a flags field. It's an enum
though only, and nothing else.
We might want to rename this externally one day, but given the compat
kludges this requires and the fact this is somewhat nichey it might not
be worth it. But internally let's rename it, as it makes things much
easier to grok, in particular as part of the codebase already exposed
the concept as mount_propagation_flag.
No actual code flow changes, just some renaming.
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.
All daemons use a similar scheme to read their main config files and theirs
drop-ins. The main config files are always stored in /etc/systemd directory and
it's easy enough to construct the name of the drop-in directories based on the
name of the main config file.
Hence the new helper does that internally, which allows to reduce and simplify
the args passed previously to config_parse_many_nulstr().
Besides the overall code simplification it results:
16 files changed, 87 insertions(+), 159 deletions(-)
it allows to identify clearly the locations in the code where configuration
files are parsed.
This makes the loggers take the most relevant object, i.e. when
applying udev rules to a device, the loggers take sd_device and
UdevRuleToken object, and when parsing udev rules, they take
UdevRuleLine or UdevRuleFile object.
To achieve that, this drops 'iterators' in UdevRules or friends named
`current_file` or so. Instead of that, each object now has its
parent object, e.g. UdevRuleToken.rule_line that references the
UdevRuleLine object the token belonging to. And each function previously
took UdevRules object now takes the most relevant object, e.g. UdevRuleToken.
Solves the discussion in https://github.com/systemd/systemd/pull/26698#discussion_r1129261193.
OMOJOLA JOSHUA
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Daan De Meyer
Mike Yuan
Yu Watanabe
Franck Bui
EinBaum
A S Alam
Topi Miettinen
tofylion
Brett Holman