Requested in https://github.com/systemd/systemd/pull/33214#discussion_r1630251308.
Also, reword error messages a bit. When /usr/lib/clock-epoch was introduced,
"build time" stopped being acurate. Just say "epoch" instead.
The same message ID is used in the manager and timesyncd. The event is
essentially equivalent for the user, and it seems reasonable that to search for
both at the same time.
The catalog entry is dropped. It provided almost no additional information above
the message. When the same message ID is now applied to messages from PID1 and
timesyncd, and the clock can be both advanced and rewound, it becomes very hard
to make the catalog entry provide something useful, because catalog entries don't
allow conditionalization.
If we're updating on a system with an invalid clock, and we're installing
a newer system version with a higher update, adjust the clock. This
way the invariant that the clock is always later than
max(compile time, timestamp file, other timestamp file) is maintained.
Also, adjust the wording of messages. When /usr/lib/clock-epoch was
introduced, "build time" stopped being acurate. Just say "epoch" instead.
Previously systemd would not use /var/lib/systemd/timesync/clock. This means
that even if /var/ is mounted when systemd is started and the file is
available, we would potentially make one time jump and than another time jump.
From a user's POV, this doesn't seem useful at all.
Also, we would always let /usr/lib/clock-epoch take priority over the built-in
epoch. But there is no guarantee that this file is actually fresh. In
particular, a user may touch /usr/lib/clock-epoch to work around a broken clock
during installation (as recommended in [1]), and then this file will grow stale
over time.
So just load the three timestamps and use the highest one as the epoch.
[1] https://discussion.fedoraproject.org/t/f38-to-f39-40-dnf-system-upgrade-can-fail-on-raspberry-pi/92403
The flag is fairly generic these days and just selects a slightly
stricter validation, with details depending on the selected dispatch
function. Hence, let's give it more precise name, in particular one that
mirrors the SD_JSON_RELAXED flag nicely (which does the opposite:
relaxes parsing)
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
It was a redundant wrapper around freecon.
test-selinux needs to be adjusted because it now needs to be linked to
libselinux, instead of pulling it in via libshared.
Anything that is part of src/shared becomes part of the shared library, which
is wasteful, because the library is linked into almost all binaries. The
library is also forms a separate link unit, so this prevents the function from
being inlined or such.
Also, move logging into the function. Now that it's not a library function,
there is no reason not to do that.
This reverts commit 1e1225614c.
This was an incomplete workaround of the race. Now that
we stop generating mount units for credential mounts,
the logic could be dropped.
While @poettering wants to keep mount units for credential
mounts, this has brought nothing but pain in real life.
By generating mount units for each cred mount, we had trouble
with default dependencies on them, which causes their stop jobs
to race with unmounting through exec_context_destroy_credentials().
There were several attempts to workaround the problem, but
none seems very graceful: #26959, #28787, #28957, #31360, #32011.
Also, we want to carry over credentials for services that
survive soft-reboot to the new mount tree, and during the practice
the stop of mount units are irritating.
The mentioned problems are ultimately resolved by disabling
default deps: #32799. But after doing that, maybe the next question
should be "why do we generate these mount units at all?"
Let's revisit the whole concept here. First of all, the credential
dirs are supposed to be opaque to users, and hence nobody should
really reference to these mounts directly. Secondly, the lifetime
of credentials is strictly bound to the service units, but nothing
else. Moreover, as more and more users of credentials pop up,
we could end up with hundreds of such mount units, which is
something we handle poorly. And we emit useless UnitRemoved signals,
etc...
As discussed, it seems that eliminating these mount units
is the correct way to go. No real use cases are impacted,
and the lifetime management becomes sane again.
Replaces #32011
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension
that enables a TCP connection to use different paths. It allows a device
to make use of multiple interfaces at once to send and receive TCP
packets over a single MPTCP connection. MPTCP can aggregate the
bandwidth of multiple interfaces or prefer the one with the lowest
latency, it also allows a fail-over if one path is down, and the traffic
is seamlessly re-injected on other paths.
To benefit from MPTCP, both the client and the server have to support
it. Multipath TCP is a backward-compatible TCP extension that is enabled
by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...).
Multipath TCP is included in the Linux kernel since version 5.6 [2]. To
use it on Linux, an application must explicitly enable it when creating
the socket:
int sd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);
No need to change anything else in the application.
This patch allows MPTCP protocol in the Socket unit configuration. So
now, a <unit>.socket can contain this to use MPTCP instead of TCP:
[Socket]
SocketProtocol=mptcp
MPTCP support has been allowed similarly to what has been already done
to allow SCTP: just one line in core/socket.c, a very simple addition
thanks to the flexible architecture already in place.
On top of that, IPPROTO_MPTCP has also been added in the list of allowed
protocols in two other places, and in the doc. It has also been added to
the missing_network.h file, for systems with an old libc -- note that it
was also required to include <netinet/in.h> in this file to avoid
redefinition errors.
Link: https://www.rfc-editor.org/rfc/rfc8684.html [1]
Link: https://www.mptcp.dev [2]
Set the $REMOTE_ADDR environment variable for AF_UNIX socket connections
when using per-connection socket activation (Accept=yes). $REMOTE_ADDR
will now contain the remote socket's file system path (starting with a
slash "/") or its address in the abstract namespace (starting with an
at symbol "@").
This information is essential for identifying the remote peer in AF_UNIX
socket connections, but it's not easy to obtain in a shell script for
example without pulling in a ton of additional tools. By setting
$REMOTE_ADDR, we make this information readily available to the
activated service.
While at it, the duplicate log of "Unit entered failed state"
is dropped. Since the state change would be logged by each
unit type already, before calling unit_notify().
CPUQuota= can deal with float percentages perfectly fine these days
(up to two places after the dot), so let's take that into account
when serializing the value to the transient unit file so we don't lose
precision when specifying e.g. "CPUQuota=0.5%".
Currently, Unit.freezer_state is always initialized to
FREEZER_RUNNING. While realizing cgroups for frozen units
was disabled in 7923e9493c,
the commit only checked for freezer_state of the unit inself,
meaning that newly-loaded units might be started and the kernel
would hang pid1 when trying to spawn sd-executor into sub-cgroup.
This can be easily reproduced by the following:
```console
# systemd-run --slice=test.slice sleep infinity
# systemctl freeze test.slice
# systemd-run --slice=test.slice sleep infinity
```
Therefore, let's correctly initialize Unit.freezer_state
based on the parent slice.
We can only do a debug log from the library, so let's add that. Callers
probably want to provide some hint when that happens, but it's very unlikely so
not worth coding in every caller.
And drop the now-unnecessary handling in unit_dequeue_rewatch_pids().
libbpf returns error codes from the kernel unmodified, and we don't understand
them so non-fatal ones are handled as hard errors.
Add a translation helper, and start by translating 524 to EOPNOTSUPP, which is
returned when nsresourced tries to use LSM BPF hooks that are not
implemented on a given arch (in this case, arm64 is misssing trampolines).
Fixes https://github.com/systemd/systemd/issues/32170
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Luca Boccassi
Yu Watanabe
Matthieu Baerts (NGI0)
Kamil Szczęk
Daan De Meyer