smb3 is an alias for modern CIFS, not the old SMB fs (see kmod alias list, i.e. modinfo fs-smb3).
(the old smbfs has long been removed from the kernel actually, it's dead
and obsolete)
devtmpfs and cpuset are not actual filesystems of their own. cpuset used
to be but is now an alias for cgroupsfs. devtmpfs is the same as tmpfs
as its just a "named superblock", i.e. a specific instance of tmpfs, but
not a file system of its own.
This group shall cover file systems whose job is to make stuff that
isn't actually storing anything in itself, and isn't just an API file
system, but allows exposing stuff with special semantics in the VFS.
1. @anonymous → for file systems that aren't real file systems but
simply the backing for sockets, pipes and other "anonymous" fds.
2. @security → for the various MAC security file systems.
This fixes the following error:
---
systemd-networkd[1449490]: ip6tnl0: Saved hardware address: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
systemd-networkd[1449490]: ip6tnl0: Failed to manage link by its new hardware address, ignoring: File exists
---
From packit/rawhide-arm64 logs:
Assertion 'limit >= INT_MAX || get_process_ppid(limit+1, NULL) == -ESRCH' failed at src/test/test-process-util.c:855, function test_get_process_ppid(). Aborting.
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
The kernel has a few different limits. In particular kernel.threads-max can be
set to some lower value, and kernel.pid_max can be set to a higher value. This
is nice because it reduces PID reuse, even if the number of threads that is
allowed is limited. But the tests assumed that we cannot have a thread with
PID above MIN(kernel.threads-max, kernel.pid_max-1), which is not valid.
So let's rework the whole thing: let's expose the helpers to read
kernel.threads-max and kernel.pid_max, and print what they return in tests.
procfs_tasks_get_limit() was something that is only used in tests, and wasn't
very well defined, so let's drop it.
Fixes#21193.
To prevent situations like in #17602 from happening, let's drop
direct recursive template dependencies. These will almost certainly
lead to infinite recursion so let's drop them immediately to avoid
instantiating potentially thousands of irrelevant units.
Example of a template that would lead to infinite recursion which
is caught by this check:
notify@.service:
```
[Unit]
Wants=notify@%n.service
```
Lennart Poettering
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Luca Boccassi
Jan Janssen