[Libguestfs] [libnbd PATCH v3 19/19] socket activation: set LISTEN_FDNAMES

[Eric Blake]

On Fri, Mar 24, 2023 at 11:32:26AM +0100, Laszlo Ersek wrote:
> 
> (4) If we pass LISTEN_PID=xxx and LISTEN_FDS=1, and rework the logic in
>     this patch to pass LISTEN_FDNAMES="unknown" in case "h->sact_name"
>     is NULL, then sd_listen_fds_with_names() will succeed in the nbd
>     server, and the single returned name ("unknown") will merge into
>     case (1), i.e., as if we had not passed (or had removed)
>     LISTEN_FDNAMES in the environment.
> 
> Therefore I propose that we implement (4). We're already populating the
> LISTEN_* variables ourselves (that is, not relying on systemd library or
> daemon logic to fill them in). I see nothing wrong with setting
> LISTEN_FDNAMES="unknown" ourselves; again that value is publicly
> specified behavior.
> 
> Case (4) also appears consistent with repeated calls to
> sd_listen_fds_with_names(). If "unset_environment" is set to nonzero in
> one of those calls, then further calls will see the internal
> sd_listen_fds() call return 0, and behave as expected. Whereas if
> "unset_environment" is never set to zero in those repeated calls, then
> "unknown" will continue to be returned from LISTEN_FDNAMES (as if via
> case (1)).
> 
> Under case (4), we should also update the API documentation in the
> previous patch ("generator: Add APIs to get/set the socket activation
> socket name"):
> 
> > +The parameter C<socket_name> can be a short alphanumeric string.
> > +If it is set to the empty string (also the default when the handle
> > +is created) then no name is passed to the server.";
> 
> we can say there, 'then the name "unknown" will be seen by the server'.

Agreed that case (4) (supplying an explicit "unkown") is the best path
forward, and with your analysis that we are not only adding a feature,
but fixing a latent bug which existed ever since systemd added
LISTEN_FDNAMES.

I'll be posting a patch to qemu shortly to unset LISTEN_FDNAMES there
as well.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org