Current text hints that machine-id in template image should be empty
if the system is read-only. But most of the bare metal systems and
regular VMs have /etc read-only at this phase of boot.
This partially reverts e86a492ff0.
The function getdents64() was introduced in glibc-2.30, and our baseline
on glibc is 2.31. Hence, we can assume the function always exists.
The posix_getdents() wrapper was introduced for compatibility with musl.
However, even the latest release of musl does not provide posix_getdents()
yet. Also, even with musl, by defining _LARGEFILE64_SOURCE, we can get
getdents64() and struct dirent64. Hence, the wrapper is anyway not
necessary.
The check existed for musl. Let's remove it, as we explicitly request glibc.
While removing the check, this also drops generic_mallinfo, introduces
a tiny converter from struct mallinfo to struct mallinfo2 if mallinfo2()
does not exist, and renames mallinfo-util.h to malloc.h.
With this change, we can drop many ifdefs and casts in .c files.
This makes
- sd-lldp-tx not send machine ID as chassis ID, but use application
specific machine ID,
- sd-lldp-tx emit vlan ID if it is running on a vlan interface,
- Describe() DBus method also reply LLDP configurations,
- io.systemd.Network.GetLLDPNeighbors varlink method provides vlan ID,
if received.
Closes#37613.
We now consider link-local addresses routable when we have configured
unicast link-local dns servers. This allows creating the DNS scope, even
when the interface doesn't get a routable address.
Previously, systemd-networkd sent machine ID as chassis ID.
Let's use application specific machine ID.
This is a kind of backward compat breaking. Hence, this also introduces
the support of $SD_LLDP_SEND_MACHINE_ID environment variable.
Closes#37613.
As explained in https://lore.kernel.org/all/20250419183545.1982187-1-shakeel.butt@linux.dev/,
writing to memory.max or memory.high triggers synchronous memory reclaim
if the limit is lowered. This can end up taking nonnegligible amounts
of time, completely blocking pid1 from doing any other work while the
reclaim is ongoing.
To address this problem, the kernel going to add O_NONBLOCK semantics
to memory.max and memory.high. If the file is opened with O_NONBLOCK,
the synchronous memory reclaim is skipped and only triggered later
without blocking the process writing the file. Let's make sure we make
use of this by opening cgroupv2 attribute files with O_NONBLOCK.
We opt to do this for all cgroupv2 attribute files, to make sure that
if the same problem happens elsewhere in the future and is fixed in the
same way, we immediately take advantage of that fix without having to
make changes in systemd as well. We probably never want to block when
writing cgroupv2 attributes and any cases where we do want to block should
indicate so explicitly instead of blocking by default.
Since shim 16, it is not possible anymore to override the security arch
protocol to avoid signature check and measurements.
Also on Dell servers, EFI_SECURITY2_ARCH_PROTOCOL is not implemented, so
unexpected measurements on PCR 4 were still happening.
This just loads and run the kernel pe. We verify that there is no
relocation needed. Also for simplification, we assume and verify that
the base address is expected to be 0.
This is a tricky one, because we effectively turn fd passing input
toggle into a tristate: unset, disabled, and enabled; whereas unset
and disabled were identical previously. *Unset* state silently
ignores SCM_RIGHTS passed by invoking recv() instead of recvmsg(),
and for disabled we now disable SO_PASSRIGHTS completely.
The plot thickens when it comes to the server, since we want to
turn off the SO_PASSRIGHTS already on the listening socket so that
there's no race between accept() and recvmsg() wrt SO_PASSRIGHTS state.
However, if we do this unconditionally, the existing use case of
creating a custom connection callback and enabling fd passing there
would be broken.
Hence, let's introduce a new flag,
SD_VARLINK_SERVER_FD_PASSING_INPUT_STRICT, which when set
ties the enablement of fd passing to SO_PASSRIGHTS in server,
and set it for all our varlink servers.
Refer to the previous commit for the rationale behind return value
change in sd_varlink_set_allow_fd_passing_input().
Currently, the socket type is only checked if the fd passing is
being enabled. The special handling seems unnecessary though,
as in the disable case, either fd passing is already false and
would be caught by the (... == !!b) shortcut at the beginning,
or the AF_UNIX check wouldn't have succeeded in the first place,
for the initial toggle to true. Hence, just uniformly check
AF_UNIX.
While at it, sd_varlink_set_allow_fd_passing_*() oddly return 1
iff changed and !b, which doesn't fit into our coding style and
I can't come up with any use case for such behavior. Let's
return 1 on changed and 0 otherwise.
sd_varlink_set_allow_fd_passing_input() will be fixed in the later
commits with other enhancements.
This controls the new SO_PASSRIGHTS socket option in kernel v6.16.
Note that I intentionally choose a different naming scheme than
Pass*=, since all other Pass*= options controls whether some extra
bits are attached to the message, while this one's about denying
file descriptor transfer and it feels more explicit this way.
And diverging from underlying socket option name is precedented
by Timestamping=. But happy to change it to just say PassRights=
if people disagree.
When adding a new interface to the object add it at the end of the list.
This way, when iterating over the list, e.g., during handling introspect
call, the order of returned interfaces will mach the order in which they
were added.
If mode= is not set in rootflags= add mode=0755 when a tmpfs
is used on the rootfs, otherwise it will be group/world writable
as that's the default mode for tmpfs filesystems.
Follow-up for 725ad3b062