This is a debugging feature. It's sometimes incredibly useful to be able
to run a second instance of homed that operates on another dir than
/home/.
Specifically, if you build homed from the source tree you can now run an
instance of it pretty reasonably directly from the build tree via:
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo SYSTEMD_HOMEWORK_PATH=$(pwd)/build/systemd-homework SYSTEMD_HOME_ROOT=/home/foo ./build/systemd-homed
And then talk to it via
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo homectl …
(you might need to tweak your dbus policy for this to work fully though)
Currently, when Xen PV domains are nested within a hypervisor which is
detected through CPUID (such as VMware), the detected hypervisor might
not be Xen, because we don't check for Xen until after the CPUID check.
This change moves the Xen check before CPUID checks to fix the issue,
and moves Dom0 checking to detect_vm_xen so that we keep ignoring Xen
when we are in Dom0.
So far we assumed every power source was a battery except for the ones
which definitely are not. I think this logic makes little sense, as
"battery" is kinda the exceptional case here, not the other way round.
Hence let's invert the type check, and denylist "Battery" devices rather
than allowlist "Mains" devices.
This should increase compatibility with alternative types of power
sources, in particular USB ones.
This takes into account that additional power types have been added
since we wrote the original code, and in particular should cover the
siutation discussed here OK:
https://sources.debian.org/src/powermgmt-base/1.36/power_supply.txt/#L31https://sources.debian.org/src/powermgmt-base/1.36/on_ac_power/#L25
Also, modernizes the code in various was ways.
Inspired by and fixes: #20964
udev: use netlink more aggressively
I'm pasting the comment from https://github.com/systemd/systemd/pull/20744#issuecomment-934485287
which is quite informative. The code wasn't changed significantly since then:
atenart commented 6 days ago:
> I ran tests without (93caec7) and with this PR (06735f2) on Fedora, having a few udev rules
> using attributes eligible to be cached and creating 50 veth on 4 CPUs. Although the time spent
> running the test is variable between runs, I generally saw an improvement when using this PR, e.g:
>
> 249-910-g93caec7:
> real 0m3.691s
> user 0m0.022s
> sys 0m1.338s
>
> 249-920-g06735f2:
> real 0m2.950s
> user 0m0.005s
> sys 0m0.399s
>
> On a different system than the one used above, I even saw a 40% improvement; results depend
> on many parameters (distro, udev rules, concurrent daemons accessing sysfs, etc.).
>
> Because it's quite hard to measure the improvement here (as the kernel behave differently between
> the two test cases), I also ran tests using a modified kernel not hitting the trylock logic. There was
> an improvement with this PR as well. (Take this with a grain of salt though, as the kernel was
> modified not using patches approved upstream).
<limits.h> calls this ULLONG_MAX. It's not clear to me where ULONGLONG_MAX
can be found. This seems to be just a mistake.
Fixes: c7ed718720 ('macro: handle overflow in ALIGN_TO() somewhat reasonably')
Based on the FIPS 198 specification. Not optimized and probably
completely unsafe, to be used only for non-strong-cryptographic
purposes when OpenSSL cannot be used.
So far we ignored if readdir_ensure_type() failed, the .d_type would
then still possibly report DT_UNKNOWN, possibly confusing the caller.
Let's make this safer: if we get an error on readdir_ensure_type() then
report it — except if it is ENOENT which indicates the dirent vanished
by now, which is not a problem and we should just skip to the next
entry.
Let's ask exactly for the one field we actually want to know, i.e.
STATX_TYPE.
(While we are at it, also copy over the inode number, if we have it,
simply to report the most recent info we have)
(Also, see AT_NO_AUTOMOUNT, so that we don't trigger automounts here.
After all, if we want to know the inode type of a dirent here, then
there's not need to trigger the automount, the inode type is not going
to change by that.)
Apparently glibc already has a helper for this. (Not in the man pages
for Linux, but FreeBSD does document these cryptic helpers, and its
exported by glibc. That should be good enough for us.)
libc nftw() shows its age a bit, let's replace it with a more moden
infra that is built around openat(), O_PATH, statx(). This makes the
interface less prone to races and cleans up the API a bit adding
substantially more functionality.
Unfortunately fgetxattr() and flistxattr() don't work via O_PATH fds.
Let's thus add fallbacks to go via /proc/self/fd/ in these cases.
Also, let's merge all the various flavours we have here into singular
implementations that can do everything we need:
1. malloc() loop handling
2. by fd, by path, or combination (i.e. a proper openat() like API)
3. work on O_PATH
It attaches the LSM BPF program when the system manager starts up.
It populates the hash of maps BPF map when services that have
RestrictFileSystems= set start.
It cleans up the hash of maps when the unit cgroup is pruned.
To pass the file descriptor of the BPF map we add it to the keep_fds
array.
Only accept DT_REG/DT_LNK/DT_DIR entries, ignore all others.
Only accpet DT_REG/DT_LNK for file names that are valid unit file names.
Only accept DT_DIR for filenames that are valid unit file names which
are suffixed by .d, .wants, .requires
This doesn't really fix any bugs, but tightens what we insert into the
lookup tables.
These functions are used pretty much independently of locale, i.e. the
only info relevant is whether th locale is UTF-8 or not. Hence let's
give this its own pair of .c/.h files.
The second call to name_to_handle_at_loop() didn't check for the specific
errors that can happen when the parent dir is mounted by nfs and instead of
falling back like it's done for the child dir, fd_is_mount_point() failed in
this case.
Lennart Poettering
Bogdan Seniuc
Zbigniew Jędrzejewski-Szmek
Thomas Haller
Luca Boccassi
Yu Watanabe
Iago Lopez Galeiras
Andrew Soutar
Franck Bui
Anita Zhang
Frantisek Sumsal