Michal Koutný [Mon, 14 Aug 2023 17:59:57 +0000 (19:59 +0200)]
cgroup: Restrict effective limits with global resource provision
Global resource (whole system or root cg's (e.g. in a container)) is
also a well-defined limit for memory and tasks, take it into account
when calculating effective limits.
Michal Koutný [Fri, 11 Aug 2023 11:51:20 +0000 (13:51 +0200)]
cgroup: Add EffectiveMemoryMax=, EffectiveMemoryHigh= and EffectiveTasksMax= properties
Users become perplexed when they run their workload in a unit with no
explicit limits configured (moreover, listing the limit property would
even show it's infinity) but they experience unexpected resource
limitation.
The memory and pid limits come as the most visible, therefore add new
unit read-only properties:
- EffectiveMemoryMax=,
- EffectiveMemoryHigh=,
- EffectiveTasksMax=.
These properties represent the most stringent limit systemd is aware of
for the given unit -- and that is typically(*) the effective value.
Implement the properties by simply traversing all parents in the
leaf-slice tree and picking the minimum value. Note that effective
limits are thus defined even for units that don't enable explicit
accounting (because of the hierarchy).
(*) The evasive case is when systemd runs in a cgroupns and cannot
reason about outer setup. Complete solution would need kernel support.
Daan De Meyer [Sun, 10 Dec 2023 21:44:25 +0000 (22:44 +0100)]
bootctl: update/list/remove all instances of systemd-boot in /EFI/BOOT
systemd-boot might be installed in /EFI/BOOT under more names than
just /EFI/BOOT/BOOTX64.efi. The prime example is shim which loads
its second stage binary from /EFI/BOOT/grubx64.efi. To accomodate
use cases where systemd-boot is installed as /EFI/BOOT/grubx64.efi,
let's always check the entire /EFI/BOOT directory for binaries that
identify as systemd-boot and list/update/remove those as well.
Let's keep this somewhat generic though and not install ourselves as
grubx64.efi since that would mean having to check for shim which is
a can of worms we probably don't want to open.
Frantisek Sumsal [Tue, 19 Dec 2023 14:05:23 +0000 (15:05 +0100)]
test: trigger /boot mount if it's an automount
If the target mount point is an automount, checking it for writeability
without triggering it first is iffy and yields different results based
on kernel version:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u36.service; invocation ID: f948ff4f3c8e4bcfba364ead94bd0ad9
+ uname -r
4.18.0-529.el8.x86_64
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=43,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=356096)
+ test '!' -w /boot
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u274.service; invocation ID: ccc53ed63c3249348cf714f97a3a7026
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot
Finished with result: success
Main processes terminated with: code=exited/status=0
One solution would be to use /boot/ instead of just /boot, which triggers
the automount during the check, but in that case the mount would happen
_after_ we apply the ProtectSystem= stuff, so the mount point would
be unexpectedly writable:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot/ || mount -l | grep boot'
Running as unit: run-u282.service; invocation ID: 2154f6b4cbd34ddeb3e246cb7c991918
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot/
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
/dev/vda2 on /boot type vfat (rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Let's just trigger the (possible) automounts explicitly before we do any
checks to avoid all this stuff.
Also, when at it, check that ProtectSystem=yes|full correctly protects
the ESP mount as well.
Lukas Nykryn [Fri, 8 Dec 2023 11:33:06 +0000 (12:33 +0100)]
udev: allow/denylist for reading sysfs attributes when composing a NIC name
Users can currently pick specific versions of NIC naming, but that
does not guarantee that NIC names won't change after the kernel adds
a new sysfs attribute.
This patch allows for an allow/deny list of sysfs attributes
that could be used when composing the name.
These lists can be supplied as an hwdb entry in the form of
/etc/udev/hwdb.d/50-net-naming-allowlist.hwdb
net:naming:drvirtio_net
ID_NET_NAME_ALLOW=0
ID_NET_NAME_ALLOW_ACPI_INDEX=1
ID_NET_NAME_ALLOW_ADDR_ASSIGN_TYPE=1
ID_NET_NAME_ALLOW_ADDRESS=1
ID_NET_NAME_ALLOW_ARI_ENABLED=1
ID_NET_NAME_ALLOW_DEV_PORT=1
ID_NET_NAME_ALLOW_FUNCTION_ID=1
ID_NET_NAME_ALLOW_IFLINK=1
ID_NET_NAME_ALLOW_INDEX=1
ID_NET_NAME_ALLOW_LABEL=1
ID_NET_NAME_ALLOW_PHYS_PORT_NAME=1
ID_NET_NAME_ALLOW_TYPE=1
Franck Bui [Thu, 14 Dec 2023 11:07:46 +0000 (12:07 +0100)]
vconsole-setup: handle the case where the vc is in KD_GRAPHICS mode more gracefully
Regardless of whether a vc path is passed, the behavior of
systemd-vconsole-setup wasn't ideal when either the passed vc or /dev/tty1 was
in graphics mode.
When a vc in graphics mode was passed, no message was emitted despite the fact
that the font settings couldn't be applied. The previous code might have
assumed that setfont(8) would throw a warning but that's not case.
When no argument was passed, systemd-vconsole-setup was supposed to
automatically select a valid tty, init it and copy the font setting to the
remaining ttys. However if the selected virtual console was in KD_GRAPHICS mode
the initialization of the font failed not only for the selected source vc but
for all of them.
Daan De Meyer [Sun, 17 Dec 2023 18:41:56 +0000 (19:41 +0100)]
shutdown: Send EXIT_STATUS before final sync
There's a race condition where the EXIT_STATUS= message we send
just before shutting down the VM doesn't arrive on the host,
presumably because the VM is shut down before the kernel has had a
chance to forward the message to the host.
Since there's no obvious way to wait until the message has been
flushed to the host, let's send the message before we execute the
final sync() instead of after executing the final sync(). In my
testing, this seems to either guarantee the message is sent or
introduces sufficient delay that the kernel always has time to flush
its socket buffers to the host.
mkosi: use systemd.firstboot=no to turn of interactivity at boot
Now that creds are processed even if systemd.firstboot=no is set, we can
use it to disable the root pw prompt *and* the new homectl prompt at the
same time, without breaking the creds stuff.
This extends what systemd-firstboot does and runs on first boots only
and either processes user records passed in via credentials to create,
or asks the user interactively to create one (only if no regular user
exists yet).
firstboot: adjust what systemd.firstboot=no on the kernel cmdline does
So far by setting systemd.firstboot=no simply short-cut the whole tool
and made it exit early. This is against what the docs say though: they
just claim the user isn't asked for questions anymore. Let's change
behaviour so that the code actually matches the docs, or more
specifically: if credentials are passed into firstboot, then honour
them, regardless of the kernel cmdline option.
After all, if we get explicit data passed in we should operate on it,
and then leave systemd.firstboot=no just affect the interactivity.
I think this was actually mostly a bug introduced because the credential
stuff was added after the kernel cmdline option, hence this just catches
up with the new addition.
resolved: increase most label buffers to fit a trailing NUL byte
This is just paranoia. In all these cases we don't really care about the
trailing NUL byte. But if there's space for it dns_label_unescape() is
going to insert it, and that's a good safety strategy.
With <para><filename>…</filename></para>, we get a separate "paragraph" for
each line, i.e. entries separated by empty lines. This uses up a lot of space
and was only done because docbook makes it hard to insert a newline. In some
other places, <literallayout> was used, but then we cannot indent the source
text (because the whitespace would end up in the final page). We can get the
desired result with <simplelist>.
With <simplelist> the items are indented in roff output, but not in html
output. In some places this looks better then no indentation, and in others it
would probably be better to have no indent. But this is a minor issue and we
cannot control that.
(I didn't convert all spots. There's a bunch of other man pages which have two
lines, e.g. an executable and service file, and it doesn't matter there so
much.)
projects / thirdparty / systemd.git / log
