Coverity flags the subtraction from msg_controllen as a potential
underflow. The CMSG_SPACE was added when send_ucred was set, and
the subtraction only runs when send_ucred was true, so it is safe.
Add an assert to document this invariant.
CID#1548074
Follow-up for 64144440a5
… and also when it fails, in the few cases where this wasn't done already.
When I was debugging https://github.com/systemd/systemd/issues/39048, it
was quite confusing that we print copious information about D-Bus messages
and all other steps we're undertaking, but nothing about the sd-notify
messages which are much more important. Add some debug messages for the
cases where we didn't print anything. (The case where $NOTIFY_SOCKET is
not set in left unchanged. The variable is often left unset and we don't
need to spam logs in that trivial case.)
Although extremely unlikely, there is a race present in solely checking the
$LISTEN_PID environment variable, due to PID recycling. Fix that by introducing
$LISTEN_PIDFDID, which contains the 64-bit ID of a pidfd for the child process
that is not subject to recycling.
We nowadays expose pidfdid at various places, e.g. envvars
and dbus properties. Also the sd_notify() MAINPID= message
has been complemented with MAINPIDFDID=. But acquiring
pidfdid is actually non-trivial especially considering
the 32-bit case, hence let's introduce a public helper
in sd-daemon specifically for that purpose.
For libsystemd's headers, the changes made depend on whether the
header is installed or not. For installed headers, the only change
made is that commonly included headers were moved to _sd-common.h.
For these headers, there should be no noticeable change in behavior
when including them. For non-installed headers, includes were replaced
with forward declarations where possible as usual.
Split out of #37344.
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
The previous commit removed the UINT_MAX check for the fd array. Let's
now re-add one, but at a better place, and with a more useful limit. As
it turns out the kernel does not allow passing more than 253 fds at the
same time, hence use that as limit. And do so immediately before
calculating the control buffer size, so that we catch multiplication
overflows.
We fucked that up in the original sd_listen() calls, and then we fixed
that on the newer flavours. But pour internal common implementation
should of course use the full range size_t, as it should be.
This then allows us to drop a redundant range check.
This cleans up the handling of the "unset_environment" parameter to
sd_listen() and related calls: the man pages claim we operate on it on
error too. Hence, actually do so in strictly all error paths. Previously
we'd miss out on some, because wrapper functions mishandled them.
This was addressed before in 362dcfc5db
but some codepaths were missed. Complete the work now.
This establishes a common pattern: a function to unset the relevant env
vars, that is called from a goto section at the botom on both success
and failure.
Let's shutdown the write end and wait for EOF from the other side
before continuing to make sure that the receiver has received all
data we sent on the socket.
We're still seeing problems in mkosi CI where we lose notify messages
sent over vsock from virtual machines because the virtual machine shuts
down before the socket buffers are flushed.
Let's try setting SO_LINGER on vsock sockets so that the kernel waits
until the buffers are flushed when we close the file descriptor.
To make sure it works, let's get rid of our previous workaround that
sends EXIT_STATUS earlier to reduce the chance of it not arriving.
This way, if it doesn't work, we'll notice it immediately due to CI
failures.
The man page says that the variable will be unset even if the call fails.
But we weren't consistent: for some errors we would return early. This
is not good, because based on the man page, the caller may use just print
a warning, or even use '(void) sd_notify(…)' for the call.
We use it for more than just pipe() arrays. For example also for
socketpair(). Hence let's give it a generic name.
Also add EBADF_TRIPLET to mirror this for things like
stdin/stdout/stderr arrays, which we use a bunch of times.
Even more than with the previous commit, this is not a trivial function
and there's no reason to believe this will actually be inlined nor that
it would be beneficial.
The function isn't necessarily fast (it's O(n)), and there's no reason
to have it defined as inline function, since it's neither fast, nor
entirely trivial.
This is preparation for #28891, which adds a bunch more helpers around
"struct iovec", at which point this really deserves its own .c/.h file.
The idea is that we sooner or later can consider "struct iovec" as an
entirely generic mechanism to reference some binary blob, and is the
go-to type for this purpose whenever we need one.
SOCK_SEQPACKET is only supported on recent kernels. Let's add a
fallback to SOCK_STREAM if it is not supported.
To accomodate SOCK_STREAM, we also modify
pid_notify_with_fds_internal() to do sendmsg() in a loop as with
SOCK_STREAM, sendmsg() is not guaranteed to write all data in a single
syscall or fail otherwise.
I guess it was only a question of time until we need to add the final
frontier of notification functions: one that combines the features of
all the others:
1. specifiying a source PID
2. taking a list of fds to send along
3. accepting a format string for the status string
Hence, let's add it.
Allow sending notifications via AF_VSOCK, so that VMs can communicate
to the hypervisor/VMM that they are finished booting.
Note that if the hypervisor does not support SOCK_DGRAM over AF_VSOCK
(ie: qemu at the time of writing), SOCK_SEQPACKET will be used instead.
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
... when called with a valid environment variable name. This means that
any time we call it with a fixed string, it is guaranteed to return 0.
(Also when the variable is not present in the environment block.)
Prompted by the discussion on #16110, let's migrate more code to
fd_wait_for_event().
This only leaves 7 places where we call into poll()/poll() directly in
our entire codebase. (one of which is fd_wait_for_event() itself)
Yu Watanabe
Luca Boccassi
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Daniel Foster
Daan De Meyer
Lennart Poettering
Luca Boccassi
Susant Sahani