The old logs used __func__, but this doesn't make sense now, because the
low-level function will be used in other places. So those are adjusted to be
more generic.
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
To notify user of kill events from systemd-oomd we now use
`SERVICE_FAILURE_OOM_KILL` as the failure result.
`unit_check_oomd_kill` now calls `notify_cgroup_oom` to
update the service result to `oom-kill`.
We add a new xattr `user.oomd_ooms` to keep track of the OOM kills
initiated by systemd-oomd, this helps us resolve a race between sending
SIGKILL to processes and checking for OOM kill status from the xattr.
Related to: #20649
When sorting paths it actually matters to use the right comparison
function. Example:
```
a/x
a-b/y
a_/z
```
I think people would probably expect this:
```
a/x
a-b/y
a_a/z
```
but if you use strcmp() instead of path_compare() you'd instead get:
```
a-b/y
a/x
a_a/z
```
That's because `/` is between `-` and `a` in the ascii table. I think
that's quite confusing, and we shouldn#t order that way hence.
As discussed: https://github.com/systemd/systemd/pull/22662#discussion_r831174776
The actual minimum size of the pool across supported kernel versions is
32 bytes. So adjust this minimum.
I've audited every single usage of random_pool_size(), and cannot see
anywhere that this would have any impact at all on anything. We could
actually just not change the constant and everything would be fine, or
we could change it here and that's fine too. From both a functionality
and crypto perspective, it doesn't really seem to make a substantive
difference any which way, so long as the value is ≥32. However, it's
better to be correct and have the function do what it says, so clamp it
to the right minimum.
systemd-udev-trigger.service by default triggeres all devices regardless
of whether they were already recognized by systemd-udevd.
There are machines (especially in embedded environments) where
systemd-udev-trigger.service is configured to run at a later stage of
the boot sequence, which can lead to quite a lot of devices being
triggered although they were already recognized by systemd-udevd.
Re-triggering a lot of devices is a relatively expensive operation and
therefore should be avoided if unnecessary.
Therefore this patch introduces --initialized-nomatch, which filters out
devices that are already present in the udev database. For consistance
reasons --initialized-match is implemented as well, which filters out devices
that are *not* already present in the udev database.
Replaces #19949.
This addresses the comment by Lennart
https://github.com/systemd/systemd/pull/22662#discussion_r829799863:
> /sys/subsystem is preparation for a future that never came.
> And given that the main proponent of this left Linux kernel
> development (Kay), I doubt this will ever come. So maybe we
> should start dropping references to /sys/subsystem/ given it's
> unlikely to materialize anytime soon.
and devices are sorted when the iteration started.
Previously, devices added by udev_enumerate_add_syspath() ->
device_enumerator_add_device() are not sorted. This fixes the issue.
bootctl so far tried to determine the layout from /etc/machine-info, but
that's obsolete, and the kernel-install script never looked there. Let's
read the setting from /etc/kernel/install.conf instead, where
kernel-install actually looks.
Support for reading the field from /etc/machine-info is retained for
compat.
This means we'll now read /etc/machine-id, /etc/machine-info and
/etc/kernel/install.conf, and read the machine ID from the former too
and the layout setting from the latter two.
We shouldn't auto-disable event sources we create in "floating" mode.
Hence don#t use the disabling destructor for event sources.
Given that noone else has access to this event source we just allocated
anyway there's no point in explicitly disabling it before freeing it.
Follow-up for ec75e8e07a
Check if process(es) of a cgroup were killed by Kernel OOM killer
or systemd-oomd before we send the cgroup empty notification.
This allows us to show the right exit state(ServiceResult)
We so far had some magic logic in place that files we open for write
with size zero are freshly created. That of course is a bogus
assumption, in particular as this code deals with corrupted file systems
which oftentimes contain zero size inodes from left-over runs.
Let's fix this properly, and actually let the kernel tell us whether it
create the file or not.
This is a wrapper around openat(). It works mostly the same, except for
one thing: it race-freely reports whether we just created the indicated
file in case O_CREAT is passed without O_EXCL.
"""
Given an array a[N] of N elements of type T:
- Forming a pointer &a[i] (or a + i) with 0 ≤ i ≤ N is safe.
- Forming a pointer &a[i] with i < 0 or i > N causes undefined behavior.
- Dereferencing a pointer &a[i] with 0 ≤ i < N is safe.
- Dereferencing a pointer &a[i] with i < 0 or i ≥ N causes undefined behavior.
"""
As pointed by by @medhefgo, here we were forming a pointer to a[-1]. a itself
wasn't NULL, so a > 0, and a-1 was also >= 0, and this didn't seem to cause any
problems. But it's better to be formally correct, especially if we move the
code to src/fundamental/ later on and compile it differently.
Compilation shows no size change (with -O0 -g) on build/systemd, so this should
have no effect whatsoever.
With my crappy home network the test takes 29.5s usually. But with any
tiny slowdown, it goes above the 30s limit and fails. Let's bump the
timeout to avoid spurious failures.
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lennart Poettering
Luca Boccassi
Nishal Kulkarni
Jason A. Donenfeld
Danilo Krummrich