From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] systemd: Also clear LISTEN_FDNAMES during systemd socket activation
Date: Mon, 27 Mar 2023 10:15:06 +0100 [thread overview]
Message-ID: <ZCFempFOjEgqyBXJ@redhat.com> (raw)
In-Reply-To: <20230324153349.1123774-1-eblake@redhat.com>
On Fri, Mar 24, 2023 at 10:33:49AM -0500, Eric Blake wrote:
> Some time after systemd documented LISTEN_PID and LISTEN_FDS for
> socket activation, they later added LISTEN_FDNAMES; now documented at:
> https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html
>
> In particular, look at the implementation of sd_listen_fds_with_names():
> https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-daemon/sd-daemon.c
>
> If we ever pass LISTEN_PID=xxx and LISTEN_FDS=n to a child process,
> but leave LISTEN_FDNAMES=... unchanged as inherited from our parent
> process, then our child process using sd_listen_fds_with_names() might
> see a mismatch in the number of names (unexpected -EINVAL failure), or
> even if the number of names matches the values of those names may be
> unexpected (with even less predictable results).
>
> Usually, this is not an issue - the point of LISTEN_PID is to tell
> systemd socket activation to ignore all other LISTEN_* if they were
> not directed to this particular pid. But if we end up consuming a
> socket directed to this qemu process, and later decide to spawn a
> child process that also needs systemd socket activation, we must
> ensure we are not leaking any stale systemd variables through to that
> child. The easiest way to do this is to wipe ALL LISTEN_* variables
> at the time we consume a socket, even if we do not yet care about a
> LISTEN_FDNAMES passed in from the parent process.
>
> See also https://lists.freedesktop.org/archives/systemd-devel/2023-March/048920.html
>
> Thanks: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> util/systemd.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-03-27 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 15:33 [PATCH] systemd: Also clear LISTEN_FDNAMES during systemd socket activation Eric Blake
2023-03-27 9:15 ` Daniel P. Berrangé [this message]
2023-04-20 15:05 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZCFempFOjEgqyBXJ@redhat.com \
--to=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.