[PATCH nbdkit 0/9] Create libnbdkit.so
by Richard W.M. Jones
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.
4 years, 1 month
[RHEL] nbdkit & libnbd for RHEL AV 8.3.0
by Richard W.M. Jones
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
4 years, 1 month
nbdkit / mingw support
by Richard W.M. Jones
Eric:
Yifan Gu has posted a few patches for mingw support. My comments
below.
https://github.com/gyf304/nbdkit/commit/a37c4ca6546dfc4e96e305af97b62e5a9...
* I think the SHARED_LDFLAGS idea is good. I pushed a slightly
different take on the idea here:
https://github.com/libguestfs/nbdkit/commit/1d634009ab8e43592065ec469df63...
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/002da4f4ca279a798fea1bf874955...
* 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/4f238c3e52a70b855dbb5f3eb3084d357...
* This one should be folded into the eventual nbdkit_functions patch.
https://github.com/gyf304/nbdkit/commit/20d888fbb8ccf33f0975a070df0d8e3d9...
* 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
4 years, 1 month
[PATCH libnbd v4] Add Go language bindings (golang) (RHBZ#1814538).
by Richard W.M. Jones
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.
4 years, 1 month
generator under Cygwin fails with: Fatal error: exception Unix.Unix_error(Unix.EAGAIN, "fork", "")
by sdaau
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?
4 years, 1 month
[PATCH nbdkit 0/3] msys2 support for review
by Richard W.M. Jones
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.
4 years, 1 month
[nbdkit PATCH] tests: Don't strand hung nbdkit processes
by Eric Blake
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
4 years, 2 months
Revisiting minimum OCaml version
by Richard W.M. Jones
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
4 years, 2 months
Re: [Libguestfs] Anyone seen build hangs (esp armv7, s390x) in Fedora?
by Eric Blake
[replying here, as I seem to have been dropped from cc on the subthread
at
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
- 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
4 years, 2 months