March 2020 - Libguestfs - libguestfs List Archives

[PATCH nbdkit 0/9] Create libnbdkit.so
by Richard W.M. Jones 26 Mar '20

26 Mar '20

This creates libnbdkit.so as discussed in the following thread: https://www.redhat.com/archives/libguestfs/2020-March/thread.html#00203 test-delay-shutdown.sh fails for unclear reasons. This series starts by reverting "tests: Don't strand hung nbdkit processes" which is because several other tests fail randomly unless I revert this patch. I didn't investigate this yet so it could be caused by this patch series. libtool on Linux doesn't appear to care about -undefined/-no-undefined. See comments in commit messages. The patch is kind of ugly TBH. Personally I don't have a problem with plugins having undefined references that are later resolved to the main binary, but I understand that Windows is broken in this regard. Rich.

2 16

[RHEL] nbdkit & libnbd for RHEL AV 8.3.0
by Richard W.M. Jones 26 Mar '20

26 Mar '20

Some thoughts on nbdkit and libnbd in RHEL Advanced Virtualization 8.3.0. We have two bugs open for rebases: * https://bugzilla.redhat.com/show_bug.cgi?id=1809231 "Rebase nbdkit to at least 1.18+ in RHEL AV 8.3.0" * https://bugzilla.redhat.com/show_bug.cgi?id=1809674 "Rebase libnbd for RHEL-AV 8.3.0" The rules for rebasing are (well, these are _my_ rules): (1) Must not introduce API/ABI incompatibility or regressions. (2) Must introduce worthwhile new features relevant to RHEL customers. (3) Must maintain any backported features from earlier RHEL. For nbdkit it makes sense to rebase to 1.18 since there are significant features relevant to virt-v2v (see my summary in https://bugzilla.redhat.com/show_bug.cgi?id=1809231#c1) So for nbdkit I have added a rhel-8.3 branch upstream, currently based on nbdkit 1.18.2. Since upstream 1.18.2 contains everything that was backported to RHEL AV 8.2 there is no need for any backports at this time. I should note that RHEL has never shipped the ext2 plugin, so the fact it was deprecated upstream (replaced with Eric's new ext2 filter) is irrelevant to RHEL. For libnbd, there are not really any significant features upstream, but the Golang bindings (not upstream yet) have been requested for RHEL (https://bugzilla.redhat.com/1814538) I think we can easily do this without rebasing, but with a cherry pick of these bindings. If there's anything I've missed, let me know. This situation could evolve as we get further requests. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

1 0

nbdkit / mingw support
by Richard W.M. Jones 25 Mar '20

25 Mar '20

Eric: Yifan Gu has posted a few patches for mingw support. My comments below. https://github.com/gyf304/nbdkit/commit/a37c4ca6546dfc4e96e305af97b62e5a9d6… * I think the SHARED_LDFLAGS idea is good. I pushed a slightly different take on the idea here: https://github.com/libguestfs/nbdkit/commit/1d634009ab8e43592065ec469df6312… It's slightly different from what Yifan posted above, because I replaced -module -avoid-version -shared with $(SHARED_LDFLAGS), adding -no-undefined additionally on mingw. * Change to .gitignore is obviously fine, but I kept the file sorted: https://github.com/libguestfs/nbdkit/commit/002da4f4ca279a798fea1bf8749558d… * Defining -D_spawnv=spawnv seems OK, but should be a separate patch. I didn't push anything. * Unclear why AM_CONDITIONAL(MINGW) is needed. It doesn't seem to be used anywhere unless I'm missing something. However if conditional compilation for mingw is needed for something, then this would be fine. * Unclear why it's necessary to rename nbdkit-common.h -> nbdkit-compat.h ? While this isn't API, it seems we should not rename it unless there's a good reason. * Functions are indirected through struct nbdkit_functions _nbdkit_functions which I guess is necessary because of PE linking (we've had similar problems with PE linking restrictions in other programs). However I wasn't very clear how this actually works, and we cannot break existing Linux binaries, so this needs more thought and must be conditional on Windows only. https://github.com/gyf304/nbdkit/commit/4f238c3e52a70b855dbb5f3eb3084d357b7… * This one should be folded into the eventual nbdkit_functions patch. https://github.com/gyf304/nbdkit/commit/20d888fbb8ccf33f0975a070df0d8e3d929… * Is there no way to get the socket peer on Windows? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

3 17

[PATCH libnbd v4] Add Go language bindings (golang) (RHBZ#1814538).
by Richard W.M. Jones 25 Mar '20

25 Mar '20

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.

2 6

generator under Cygwin fails with: Fatal error: exception Unix.Unix_error(Unix.EAGAIN, "fork", "")
by sdaau 24 Mar '20

24 Mar '20

Hi all, Copy of: generator under Cygwin fails with: Fatal error: exception Unix.Unix_error(Unix.EAGAIN, "fork", "") · Issue #45 · libguestfs/libguestfs https://github.com/libguestfs/libguestfs/issues/45 ... since I realised late I shouldn't post on GitHub issues. I managed to pass the configure stage in Cygwin on windows 10 with: CFLAGS=-fPIC ./autogen.sh --disable-daemon --disable-appliance --with-distro=cygwin ... (and installing relevant Cygwin libraries), with version: ``` user@PC /cygdrive/c/src/libguestfs_git $ git log --oneline -1 088b6d1c8 (HEAD -> master, origin/master, origin/HEAD) get-kernel: fallback to uncompressed vmlinux kernels ``` The setup at end of configure is this: ``` Thank you for downloading libguestfs 1.42.0 This is how we have configured the optional components for you today: Daemon .............................. no Appliance ........................... no QEMU ................................ /cygdrive/c/bin/qemu/qemu-system-x86_64 guestfish and C-based virt tools .... yes FUSE filesystem ..................... yes Default backend ..................... direct GNU gettext for i18n ................ yes OCaml bindings ...................... yes OCaml-based virt tools .............. yes Perl bindings ....................... no Perl-based virt tools ............... no Python bindings ..................... yes Ruby bindings ....................... no Java bindings ....................... no Haskell bindings .................... no PHP bindings ........................ no Erlang bindings ..................... no Lua bindings ........................ no Go bindings ......................... no gobject bindings .................... yes gobject introspection ............... yes Vala bindings ....................... no bash completion ..................... yes Rust bindings ....................... no ``` After that, `make` fails with the following error, which I managed to reconstruct like this: ``` user@PC /cygdrive/c/src/libguestfs_git $ make -C generator clean make: Entering directory '/cygdrive/c/src/libguestfs_git/generator' test -z "*~ *.bak *.orig *.rej *.cmi *.cmo *.cma *.cmx *.cmxa dll*.so *.a *.annot oUnit-*.cache oUnit-*.log *.1 *.3 *.5 *.8 stamp-*.pod bindtests.tmp stamp-generator generator" || rm -f *~ *.bak *.orig *.rej *.cmi *.cmo *.cma *.cmx *.cmxa dll*.so *.a *.annot oUnit-*.cache oUnit-*.log *.1 *.3 *.5 *.8 stamp-*.pod bindtests.tmp stamp-generator generator rm -rf .libs _libs rm -f *.lo make: Leaving directory '/cygdrive/c/src/libguestfs_git/generator' user@PC /cygdrive/c/src/libguestfs_git $ make -C generator make: Entering directory '/cygdrive/c/src/libguestfs_git/generator' OCAMLCMI types.cmi OCAMLC types.cmo OCAMLCMI memoized_cache.cmi OCAMLC memoized_cache.cmo OCAMLCMI utils.cmi OCAMLC utils.cmo OCAMLCMI proc_nr.cmi OCAMLC proc_nr.cmo OCAMLCMI actions_augeas.cmi OCAMLC actions_augeas.cmo OCAMLCMI actions_core.cmi OCAMLC actions_core.cmo OCAMLCMI actions_core_deprecated.cmi OCAMLC actions_core_deprecated.cmo OCAMLCMI actions_debug.cmi OCAMLC actions_debug.cmo OCAMLCMI actions_hivex.cmi OCAMLC actions_hivex.cmo OCAMLCMI actions_hivex_deprecated.cmi OCAMLC actions_hivex_deprecated.cmo OCAMLCMI actions_inspection.cmi OCAMLC actions_inspection.cmo OCAMLCMI actions_inspection_deprecated.cmi OCAMLC actions_inspection_deprecated.cmo OCAMLCMI actions_internal_tests.cmi OCAMLC actions_internal_tests.cmo OCAMLCMI actions_properties.cmi OCAMLC actions_properties.cmo OCAMLCMI actions_properties_deprecated.cmi OCAMLC actions_properties_deprecated.cmo OCAMLCMI actions_tsk.cmi OCAMLC actions_tsk.cmo OCAMLCMI actions_yara.cmi OCAMLC actions_yara.cmo OCAMLCMI actions.cmi OCAMLC actions.cmo OCAMLCMI structs.cmi OCAMLC structs.cmo OCAMLCMI fish_commands.cmi OCAMLC fish_commands.cmo OCAMLCMI optgroups.cmi OCAMLC optgroups.cmo OCAMLCMI prepopts.cmi OCAMLC prepopts.cmo OCAMLCMI events.cmi OCAMLC events.cmo OCAMLCMI pr.cmi OCAMLC pr.cmo OCAMLCMI docstrings.cmi OCAMLC docstrings.cmo OCAMLCMI authors.cmi OCAMLC authors.cmo OCAMLCMI checks.cmi OCAMLC checks.cmo OCAMLCMI c.cmi OCAMLC c.cmo OCAMLCMI XDR.cmi OCAMLC XDR.cmo OCAMLCMI daemon.cmi OCAMLC daemon.cmo OCAMLCMI tests_c_api.cmi OCAMLC tests_c_api.cmo OCAMLCMI fish.cmi OCAMLC fish.cmo OCAMLCMI OCaml.cmi OCAMLC OCaml.cmo OCAMLCMI perl.cmi OCAMLC perl.cmo OCAMLCMI python.cmi OCAMLC python.cmo OCAMLCMI ruby.cmi OCAMLC ruby.cmo OCAMLCMI java.cmi OCAMLC java.cmo OCAMLCMI haskell.cmi OCAMLC haskell.cmo OCAMLCMI csharp.cmi OCAMLC csharp.cmo OCAMLCMI php.cmi OCAMLC php.cmo OCAMLCMI erlang.cmi OCAMLC erlang.cmo OCAMLCMI lua.cmi OCAMLC lua.cmo OCAMLCMI GObject.cmi OCAMLC GObject.cmo OCAMLCMI golang.cmi OCAMLC golang.cmo OCAMLCMI rust.cmi OCAMLC rust.cmo OCAMLCMI bindtests.cmi OCAMLC bindtests.cmo OCAMLCMI errnostring.cmi OCAMLC errnostring.cmo OCAMLCMI customize.cmi OCAMLC customize.cmo OCAMLCMI UEFI.cmi OCAMLC UEFI.cmo OCAMLCMI main.cmi OCAMLC main.cmo make -C ../common/mlstdutils mlstdutils.cma make[1]: Entering directory '/cygdrive/c/src/libguestfs_git/common/mlstdutils' make[1]: 'mlstdutils.cma' is up to date. make[1]: Leaving directory '/cygdrive/c/src/libguestfs_git/common/mlstdutils' ocamlfind ocamlc -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt '-fPIC -fno-strict-overflow -Wno-strict-overflow' \ -package unix,str -I . -I . -I ../common/mlstdutils -I ../common/mlstdutils -linkpkg mlstdutils.cma \ types.cmo memoized_cache.cmo utils.cmo proc_nr.cmo actions_augeas.cmo actions_core.cmo actions_core_deprecated.cmo actions_debug.cmo actions_hivex.cmo actions_hivex_deprecated.cmo actions_inspection.cmo actions_inspection_deprecated.cmo actions_internal_tests.cmo actions_properties.cmo actions_properties_deprecated.cmo actions_tsk.cmo actions_yara.cmo actions.cmo structs.cmo fish_commands.cmo optgroups.cmo prepopts.cmo events.cmo pr.cmo docstrings.cmo authors.cmo checks.cmo c.cmo XDR.cmo daemon.cmo tests_c_api.cmo fish.cmo OCaml.cmo perl.cmo python.cmo ruby.cmo java.cmo haskell.cmo csharp.cmo php.cmo erlang.cmo lua.cmo GObject.cmo golang.cmo rust.cmo bindtests.cmo errnostring.cmo customize.cmo UEFI.cmo main.cmo -o generator mkdir -p ../perl/lib/Sys mkdir -p ../ruby/ext/guestfs mkdir -p ../java/com/redhat/et/libguestfs mkdir -p ../csharp mkdir -p ../gobject/src mkdir -p ../gobject/include mkdir -p ../gobject/include/guestfs-gobject cd .. && /cygdrive/c/src/libguestfs_git/generator/generator 0 [main] generator 3260 dofork: child -1 - forked process 14884 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 Fatal error: exception Unix.Unix_error(Unix.EAGAIN, "fork", "") make: *** [Makefile:2244: stamp-generator] Error 2 make: Leaving directory '/cygdrive/c/src/libguestfs_git/generator' ``` For some reason, even if there is `-g` in `OCAML_FLAGS = -g -annot -safe-string`, also `ocamldebug` fails to reveal anything (although, admittedly, this is first time in my life I've ever run `ocamldebug`, or had anything to do with OCaml): ``` $ ocamldebug -cd generator generator OCaml Debugger version 4.04.2 (ocd) step Loading program... 0 [main] ocamldebug 4271 dofork: child -1 - forked process 1276 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 Unix error: 'fork' failed: Resource temporarily unavailable (ocd) q ``` However, gdb reveals some threads are started before the crash: ``` $ gdb --args generator/generator GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from generator/generator...(no debugging symbols found)...done. (gdb) r Starting program: /cygdrive/d/src/libguestfs_git/generator/generator [New Thread 3712.0x1b8c] [New Thread 3712.0x2744] [New Thread 3712.0x1b20] [New Thread 3712.0x30d4] [New Thread 3712.0x33b8] 0 [main] generator 4275 dofork: child -1 - forked process 13456 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 Fatal error: exception Unix.Unix_error(Unix.EAGAIN, "fork", "") [Thread 3712.0x33b8 exited with code 2] [Thread 3712.0x1b20 exited with code 2] [Thread 3712.0x2744 exited with code 2] [Inferior 1 (process 3712) exited with code 02] (gdb) q ``` Any suggestions if I can get generator running on Cygwin?

2 2

[PATCH libnbd v3] Add Go language bindings (golang) (RHBZ#1814538).
by Richard W.M. Jones 24 Mar '20

24 Mar '20

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the golang side, but ... really? For ease of review I have placed the generated golang/src/libguestfs.org/libnbd directory here: http://oirase.annexia.org/tmp/libnbd-go/ Rich.

1 1

[PATCH nbdkit 0/3] msys2 support for review
by Richard W.M. Jones 23 Mar '20

23 Mar '20

I pushed a few of the msys2 patches upstream. I changed the way that $(SHARED_LDFLAGS) works so it's more to my liking, and the others were pushed unchanged. Three patches remain which I'm posting on the mailing list for proper review. Rich.

2 8

[nbdkit PATCH] tests: Don't strand hung nbdkit processes
by Eric Blake 20 Mar '20

20 Mar '20

We've recently been hitting a transient hung rpm build when using make 4.3, due to a bug in test-nbd-tls-psk.sh. We're still trying to isolate the correct fix for that bug (it might be in the nbd plugin proper, but more likely is an issue in libnbd's tls handling of connection close), but in the meantime, this patch should at least cause a graceful fail rather than make hanging due to an nbdkit process that has hung. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- tests/functions.sh.in | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/tests/functions.sh.in b/tests/functions.sh.in index 8406fcf9..e483505e 100644 --- a/tests/functions.sh.in +++ b/tests/functions.sh.in @@ -85,8 +85,8 @@ requires_ipv6_loopback () # instead. It's very unlikely that port 1 is open. if LANG=C qemu-img info "nbd:[::1]:1" |& \ grep -sq "Address family for hostname not supported"; then - echo "$0: IPv6 loopback is not available, skipping this test" - exit 77 + echo "$0: IPv6 loopback is not available, skipping this test" + exit 77 fi } @@ -139,7 +139,32 @@ start_nbdkit () fi # Kill nbdkit on exit. - cleanup_fn kill "$(cat "$pidfile")" + cleanup_fn kill_nbdkit "$(cat "$pidfile")" +} + +# kill_nbdkit pid +# +# End the nbkdit process that created pidfile. Exit this script with an +# error if nbdkit does not gracefully shutdown in a timely manner. +kill_nbdkit () +{ + local pid=$1 i + + # Start with SIGTERM, and wait for graceful exit + kill $pid + for i in {1..60}; do + if ! kill -0 $pid 2>/dev/null; then + break + fi + sleep 1 + done + # If nbdkit has not exited, try SIGKILL and fail the test + if test $i = 60; then + echo "error: nbdkit pid $pid failed to respond to SIGTERM" + kill -9 $pid + # Append our failure after other cleanups + cleanup_fn exit 1 + fi } # foreach_plugin f [args] -- 2.25.1

2 2

Revisiting minimum OCaml version
by Richard W.M. Jones 20 Mar '20

20 Mar '20

Previously discussed: https://www.redhat.com/archives/libguestfs/2017-September/msg00203.html Currently libguestfs and virt-v2v require OCaml >= 4.01. (That's perhaps theoretical, as I don't think anyone is really compiling them with such an old compiler). This causes a bunch of trouble. To my mind the major things are: - Having to have the "Bytes" compatibility module (added in OCaml 4.02). - Conditional on -runtime-variant _pic (added in OCaml 4.03). - Not being able to use ppx extension points, which means we have lots of repetitive string_of_* functions that could be mostly eliminated (needs OCaml >= 4.02). - Match + catch (needs OCaml >= 4.02) https://blog.janestreet.com/pattern-matching-and-exception-handling-unite/ - Warnings about "noalloc" (>= 4.03) and "Pervasives" (>= 4.07). I guess it's also the case that some dependencies that we require don't actually work on OCaml 4.01. Here are some common distros and the versions of OCaml available: Arch (Extra) OCaml 4.09 Debian stable OCaml 4.05 Debian testing OCaml 4.08 Fedora 31 OCaml 4.08 OpenSUSE OCaml 4.05 RHEL 7 OCaml 4.05 RHEL 8 OCaml 4.07 Ubuntu 16.04 OCaml 4.02 Ubuntu 18.04 OCaml 4.05 Here are the release dates of the OCaml compiler: OCaml version Release date 4.02 2014-08 4.03 2016-04 4.04 2016-11 4.05 2017-07 4.06 2017-11 4.07 2018-07 4.08 2019-06 4.09 2019-09 4.10 2020 I think we should move the minimum to 4.05 since that covers everything except the old Ubuntu LTS (and that's their fault for releasing an LTS with a version of OCaml which was already nearly 2 years out of date, and not updating it in the meantime). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

2 1

Re: [Libguestfs] Anyone seen build hangs (esp armv7, s390x) in Fedora?
by Eric Blake 20 Mar '20

20 Mar '20

[replying here, as I seem to have been dropped from cc on the subthread at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… - maybe I should subscribe to devel@ instead of seeing this second-hand... hmm - I can't even post to devel@ without subscribing, so now just sending this to libguestfs] [adding libguestfs - now that devel@ has helped point to a bug in nbdkit itself] On 3/18/20 4:49 AM, Richard W.M. Jones wrote: > On Wed, Mar 18, 2020 at 09:38:52AM +0000, Peter Robinson wrote: >>> This might be a bug in the package itself, but has anyone seen builds >>> hanging in weird places, in Rawhide, especially on armv7 and s390x? >>> >>> This packge build has hung 3 times in the same place, once on armv7 >>> and twice on s390x: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=42570766 >>> >>> It's hard to explain how it could hang at that place in the build >>> unless something fundamental is broken like make. >> >> Well make 4.3 did land recently (March 12th) in rawhide so that's >> entirely possible. > > Yes, Eric Blake pointed this out to me too. However I don't really > want to blame make unless others have seen similar hangs. It could > easily be a new bug in the package itself. > > If anyone has access to that builder, it might be interesting to get a > process listing, or strace of whatever process is hanging. Dan Horak added: > it's a deadlock in the tests, not in make. Reproduced with "fedpkg local" in a cycle. > sharkcz 1649225 0.0 0.0 222288 3904 pts/5 S+ 06:24 0:00 /bin/sh -e /var/tmp/rpm-tmp.RXcMRr > sharkcz 1649230 0.0 0.0 10372 3248 pts/5 S+ 06:24 0:00 make -j4 check > sharkcz 1658088 0.0 0.0 251236 3400 pts/5 Sl+ 06:25 0:00 /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P test-nbd-tls-psk.pid1 -U /tmp/tmp.7e7Gv5MPmZ --tls=require --tls-psk=keys.psk -- /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/example1/.libs/nbdkit-example1-plugin.so > sharkcz 1658091 0.0 0.1 192944 4464 pts/5 Sl+ 06:25 0:00 /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P test-nbd-tls-psk.pid2 -U /tmp/tmp.yp61yXx09y --tls=off -- /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/nbd/.libs/nbdkit-nbd-plugin.so tls=require tls-psk=keys.psk tls-username=qemu socket=/tmp/tmp.7e7Gv5MPmZ > the 2 nbdkit processes are stuck in the futex() syscall Reconstructing state from those command lines - we have a TLS test that operates 3 processes: client <=> nbdkit nbd <=> nbdkit example1 it looks like this particular test was checking a plain-text client connecting to nbdkit nbd, which in turn was connecting as a TLS client to nbdkit example1. I also know that 'nbdkit nbd' uses libnbd to support TLS, and that we have not fully implemented clean TLS teardown in libnbd - so it could be that the nbd side has told the example1 side that it will be shutting down soon, but due to unclean TLS library usage, is missing a poll() wakeup to realize that there will be no further response coming from the example1 side; while the example1 side is doing blocking I/O waiting for the nbd side to close the socket. The overall test that spawned both nbdkit processes in the background (tests/test-nbd-tls-psk.sh) has completed, though, stranding those two hung child processes without their original parent but letting 'make check' report testsuite success. As to why make is hanging, that is beyond me. Maybe something new in make 4.3 is detecting that we have stranded indirect processes, and is waiting for them to complete? Ideally, we need to fix libnbd TLS support to do cleaner shutdown. Pragmatically, nbdkit's tests/functions.sh start_nbdkit() function right now tries only a single: cleanup_fn kill "$(cat "$pidfile")" without waiting to see if it actually worked. We could probably turn that into a more robust kill_nbdkit() function that first tries the graceful SIGTERM, waits a few seconds to confirm whether the process actually died, and follows up with a harder SIGKILL as needed (preferably failing a test whenever SIGTERM was insufficient). It may not solve the bug in libnbd TLS shutdown, but would at least prevent stuck processes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

1 1