On Sun, Aug 25, 2024 at 02:13:39PM GMT, Richard W.M. Jones wrote:
> While debugging an ugly nbdkit / OCaml crash[1] which only happened
> when nbdkit was run as a subprocess of libnbd, I needed a way to start
> gdb attached to nbdkit.  It's not possible to do this by running
> "gdb --args nbdkit -s ..." as a command for various reasons.
> 
> My solution to this was (error checking removed for clarity):
> 
>   nbd_connect_command (nbd, { "nbdkit", "-s" /* ... */});
>   char pid[100];
>   snprintf (pid, sizeof pid, "%d", nbd->pid);
>   if (fork () > 0) {
>     execl ("/usr/bin/gdb", "gdb", "../server/nbdkit", pid, NULL);
>     _exit (1);
>   }
>   while (access ("/tmp/continue", F_OK) != 0) {
>     sleep (1);
>   }
>   /* Test case continues after the file is created. */
> 
> In this case I was fishing directly into the private nbd_handle struct
> to get the pid field.  However this seems like a genuine (if rare)
> case for being able to get the process ID directly.
> 
> The documentation is written to be clear that this is only useful for
> debugging cases, only works on some platforms, and shouldn't be relied
> on more generally.

Since we have given the appropriate disclaimer about it being mainly
useful to debugging sessions, I don't see a problem with including
this.

> 
> [1] 
> https://discuss.ocaml.org/t/free-uninitalized-data-when-calling-caml-c-thread-unregister-on-the-main-thread/15198

Quite a debug session you went through there.

> +
> +  "get_subprocess_pid", {
> +    default_call with
> +    args = []; ret = RInt64;
> +    shortdesc = "get the process ID of the subprocess";
> +    longdesc = "\
> +For connections which create a subprocess such as
> +L<nbd_connect_command(3)>, this returns the process ID (PID)
> +of the subprocess.  This is only supported on some platforms.
> +
> +This is mainly useful in debugging cases.  For example we used
> +this to attach L<gdb(1)> to an nbdkit subprocess that was crashing
> +inside a plugin.";

The first-person past-tense tone of the sentence is a bit out of
character with the rest of the documentation.  Maybe simplify it to
just:

For example, this could be used to learn where to attach L<gdb(1)> to
diagnose a crash in an nbdkit subprocess.

> +++ b/tests/get-subprocess-pid.c

> +int
> +main (int argc, char *argv[])
> +{
> +  struct nbd_handle *nbd;
> +  int64_t pid;
> +  const char *cmd[] = { NBDKIT, "-s", "--exit-with-parent",
> +                        "memory", "size=1m", NULL };

Is there any (easy?) way to get nbdkit to confess its own pid, to
compare that it matches with what we queried from libnbd?  Maybe we
want to add a new mode to 'nbdkit info mode=pid' which exposes its own
pid as the lone big-endian 8-byte value of the export?  (Of course,
willingly exposing your pid over the network makes it that much easier
for clients to try and compromise that pid - but it's no worse than
'nbdkit info mode=time' documenting that exposing the server's
wallclock time may be insecure)

Reviewed-by: Eric Blake <ebl...@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org
_______________________________________________
Libguestfs mailing list -- guestfs@lists.libguestfs.org
To unsubscribe send an email to guestfs-le...@lists.libguestfs.org

Reply via email to