I got the logic reversed in 6d93265955.
Let's just remove the conditionalization of the status message: if we're
sending something, we might just as well always attach READY=1, the extra
few bytes don't make much of a difference.
FWIW, it seems that this bug didn't cause problems, probably because we'd send
READY=1 either from user_manager_send_ready() or from a later call to
manager_send_ready().
Most sd_notify() calls are like log_info() — the result is only informative
and if they fail, it's best ignore this. But if a call with READY=1 fails,
the unit may enter a failed state, so we should warn about this. Similarly
for FSTOREREMOVE=1: the manager may be left with a stale fd, at least wasting
resources.
… but only for a single variable.
The guidelines already allowed declaring variables at the point of
initialization. But not making a function call to do that. Let's allow that
now. The existing style of declaring and initializing seperate is still
allowed, and whatever makes most sense should be used.
It is only added in the one place where we actually try to set the
setting to a new value. Before we were testing if we can set to it the
existing value, which was a noop. We could still get a permission error,
but this is the first place where we would propagate EROFS.
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.
This test makes assumptions on the availability of some mappings contained in
kbd-model-map and therefore strongly relies on the version shipped by
upstream. IOW the test is likely to fail if it's installed on a system with a
more comprehensive kbd-model-map.
This patch makes the upstream kbd-model-map file available via a symlink in
test/testdata/test-keymap-util dir and makes sure that this specific version is
always used by test-keymap-util regardless of whether the test is installed and
run on a different system or directly run (optionally via meson) from the
project working dir.
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.
These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.
See: #20230#19208
When `SELinuxContext=` parameter is prefixed with `-`, the documentation states
that any errors determining or changing context should be ignored, but this
doesn't actually happen and the service may fail with `229/SELINUX_CONTEXT`.
Fix by adding checks to `context->selinux_context_ignore`.
Closes: #21057
Doing start rate limit checks before doing condition checks made
condition check failures count towards the start rate limit which
broke existing assumptions (see #21025). Run the rate limit checks
after the condition checks again to restore the previous behaviour.
We're actually falling back to `more` in the mkosi image which doesn't
behave quite the same as less which is somewhat annoying. Let's make
sure `less` is installed so systemd can use it as the pager.
The checks for finding a new available address in the pool were broken in two
ways: not using UINT32_TO_PTR() on hashmap lookups resulted in false negatives,
and the check wasn't skipping the server address if that was part of the pool.
Move the check for available addresses to a small helper function and fix both
issues, and also add a check to the REQUEST code for the server address.
The DHCP server configuration supports setting a maximum lease time, but old
leases are never actually cleared out if the client doesn't send a RELEASE.
This causes the pool to run out of addresses on networks where clients just
disappear, which is a fairly common occurrence on wireless networks.
Fix this by cleaning up expired leases before processing client requests, so
addresses can be reused for new clients.
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Franck Bui
Frantisek Sumsal
Daan De Meyer
Topi Miettinen
Toke Høiland-Jørgensen