A later version of the DefaultMemory{Low,Min} patch changed these to
require explicitly setting memory_foo_set, but we only set that in
load-fragment, not dbus-cgroup.
Without these, we may fall back to either DefaultMemoryFoo or
CGROUP_LIMIT_MIN when we really shouldn't.
This is an oversight from https://github.com/systemd/systemd/pull/12332.
Sadly the tests didn't catch it since it requires a real cgroup
hierarchy to see, and it wasn't seen in prod since we're only currently
using DefaultMemoryLow, not DefaultMemoryMin. :-(
Currently systemd will treat smb3 as local filesystem and cause
can't boot failures. Add smb3 to the list of remote filesystems
to fix this issue.
Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
As documented in the man-page, readdir() may return a directory entry with
d_type == DT_UNKNOWN. This must be handled for regular filesystems.
dirent_ensure_type() is available to set d_type if necessary. Use it in
some more places.
Without this systemd will fail to boot correctly with nfsroot and some
other filesystems.
Closes#13609
On one of my test machines, test-path-util was failing because the
find_binary("xxxx-xxxx") was returning -EACCES instead of -ENOENT. This
happens because the PATH entry on that host contains a directory which
the user in question doesn't have access to. Typically applications
ignore permission errors when searching through PATH, for example in
bash:
$ whoami
cdown
$ PATH=/root:/bin type sh
sh is /bin/sh
This behaviour is present on zsh and other shells as well, though. This
patch brings our PATH search behaviour closer to other major Unix tools.
IPServiceType set to CS6 (network control) causes problems on some old
network setups that continue to interpret the field as IP TOS.
Make DHCP work on such networks by allowing this field to be set to
CS4 (Realtime) instead, as this maps to IPTOS_LOWDELAY.
Signed-off-by: Siddharth Chandrasekaran <csiddharth@vmware.com>
See https://bugzilla.redhat.com/show_bug.cgi?id=1731772:
when autofs4 is disabled in the kernel,
proc-sys-fs-binfmt_misc.automount is not started, so the binfmt_misc module is
never loaded. If we added a dependency on proc-sys-fs-binfmt_misc.mount
to systemd-binfmt.service, things would work even if autofs4 was disabled, but
we would unconditionally pull in the module and mount, which we don't want to do.
(Right now we ony load the module if some binfmt is configured.)
But let's make it easier to handle this case by doing two changes:
1. order systemd-binfmt.service after the .mount unit (so that the .service
can count on the mount if both units are pulled in, even if .automount
is skipped)
2. add [Install] section to the service unit. This way the user can do
'systemctl enable proc-sys-fs-binfmt_misc.mount' to get the appropriate behaviour.
ARPHRD_NETROM was excluded, most likely just because it is protocol No. 0,
and ARPHRD_CISCO was reported under its alias name "HDLC". Let's just
allow defined aliases under the main name.
Our biggest object in libsystemd was a table full of zeros, for the arphdr
names. Let's use a switch (which gcc nicely optimizes for us), instead a
table with a gap between 826 and 65534:
$ ls -l build{,2}/src/basic/a6ba3eb@@basic@sta/arphrd-list.c.o
-rw-rw-r--. 1 zbyszek zbyszek 540232 Sep 22 00:29 build/src/basic/a6ba3eb\@\@basic\@sta/arphrd-list.c.o
-rw-rw-r--. 1 zbyszek zbyszek 20512 Sep 25 11:56 build2/src/basic/a6ba3eb\@\@basic\@sta/arphrd-list.c.o
$ ls -l build{,2}/src/shared/libsystemd-shared-243.so
-rwxrwxr-x. 1 zbyszek zbyszek 6774368 Sep 22 00:29 build/src/shared/libsystemd-shared-243.so
-rwxrwxr-x. 1 zbyszek zbyszek 6254808 Sep 25 12:16 build2/src/shared/libsystemd-shared-243.so
No functional change.
Introduce support for configuring cpus and mems for processes using
cgroup v2 CPUSET controller. This allows users to limit which cpus
and memory NUMA nodes can be used by processes to better utilize
system resources.
The cgroup v2 interfaces to control it are cpuset.cpus and cpuset.mems
where the requested configuration is written. However, it doesn't mean
that the requested configuration will be actually used as parent cgroup
may limit the cpus or mems as well. In order to reflect the real
configuration cgroup v2 provides read-only files cpuset.cpus.effective
and cpuset.mems.effective which are exported to users as well.
We have the problem that many early boot or late shutdown issues are harder
to solve than they could be because we have no logs. When journald is not
running, messages are redirected to /dev/kmsg. It is also the time when many
things happen in a rapid succession, so we tend to hit the kernel printk
ratelimit fairly reliably. The end result is that we get no logs from the time
where they would be most useful. Thus let's disable the kernels ratelimit.
Once the system is up and running, the ratelimit is not a problem. But during
normal runtime, things also log to journald, and not to /dev/kmsg, so the
ratelimit is not useful. Hence, there doesn't seem to be much point in trying
to restore the ratelimit after boot is finished and journald is up and running.
See kernel's commit 750afe7babd117daabebf4855da18e4418ea845e for the
description of the kenrel interface. Our setting has lower precedence than
explicit configuration on the kenrel command line.
"ratelimit" is a real word, so we don't need to use the other form anywhere.
We had both forms in various places, let's standarize on the shorter and more
correct one.
The RFC states that lifetime (AdvDefaultLifetime) must be at least
MaxRtrAdvInterval (which more or less corresponds to SD_RADV_DEFAULT_MAX_TIMEOUT_USEC
in systemd).
To fulfill this limit, virtually lower MaxRtrAdvInterval and MinRtrAdvInterval
accordingly.
Also check that min is not lower than 3s and max is not lower than 4s.
