Re: [Libguestfs] [PATCH libnbd] api: New nbd_kill_command API for sending a signal to the command subprocess.

Eric Blake
Thu, 25 Jul 2019 20:19:23 -0000

On 7/25/19 2:15 PM, Richard W.M. Jones wrote:
> Reverts commit 387cbe67c3db27e8a61117fedb6e7fad76e409ef.
> ---
>  generator/generator       | 18 +++++++++++++++++-
>  lib/handle.c              | 28 +++++++++++++++++++++++++++-
>  tests/closure-lifetimes.c |  4 +++-
>  3 files changed, 47 insertions(+), 3 deletions(-)

tests/server-death.c can be simplified (no longer has to use --pidfile
to learn where to send its kill); could be done on top.

> +  "kill_command", {
> +    default_call with
> +    args = [ Int "signal" ]; ret = RErr;
> +    shortdesc = "kill server running as a subprocess";
> +    longdesc = "\
> +This call may be used to kill the server running as a subprocess
> +that was previously created using C<nbd_connect_command>.  You
> +do not need to use this call.  It is only needed if the server
> +does not exit when the socket is closed.
> +
> +The C<signal> flag is the optional signal number to send
> +(see L<signal(7)>).  If signal is C<0> then C<SIGTERM>
is sent.";

[1]


> +int
> +nbd_unlocked_kill_command (struct nbd_handle *h, int signal)
> +{

Is gcc -Wshadow going to annoy us by this choice of naming?  I'd use
signum, if we're worried.

> @@ -149,6 +150,7 @@ main (int argc, char *argv[])
>                                                read_cb, NULL,
>                                                completion_cb, NULL, 0);
>    if (cookie == -1) NBD_ERROR;
> +  nbd_kill_command (nbd, 0);

This looks a bit funny until I read the docs at [1].  When using
kill(2), I'm used to the function call 'kill(pid, 0)' probing for
process existence.  But on the command line, kill(1) has the behavior of
sending SIGTERM by default when you omit a signal number (and not
serving as a process existence probe).

I guess our decision on what to do with the client requesting signal=0
boils down to whether we think nbd_is_dead() (for checking that the
socket has gone away, but not necessarily if the subprocess still
exists) and the knowledge that nbd_close() does wait() on the subprocess
is sufficient for avoiding the need to do any direct probing.

Thus, ACK with your wording fix.

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