[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libguestfs] question on nbdkit shutdown behavior



I'm observing a difference in timing on nbdkit shutdown that is
dependent on client behavior, and I wonder if that's a bug, but I can't
figure out where to patch it.

When there is no connection present, sending SIGINT to nbdkit terminates
immediately.

If, on the other hand, there is a single client currently connected, the
termination behavior on SIGINT depends on what the client has done: if
the client is currently silent with regards to issuing
transmission-phase transactions, nbdkit hangs for 5 seconds, then
forcibly tears down the connection:

term1$ ./nbdkit -f -v -n file file=TODO
...
nbdkit: debug: bound to IP address <any>:10809 (2 socket(s))

term2$ qemu-io -f raw nbd://localhost:10809/ -r
qemu-io>

term1$ ^C
nbdkit: debug: waiting for running threads to complete
nbdkit: debug: waited 5s for running threads to complete
nbdkit: debug:
/home/eblake/nbdkit/plugins/file/.libs/nbdkit-file-plugin.so: unload

term2$
qemu-io> r 0 1
read failed: Input/output error
qemu-io> q


But, if the client makes ANY transaction during that window, then nbdkit
lets that transaction succeed, then tears down the connection without
any further wait:

term1$ ./nbdkit -f -v -n file file=TODO
...
nbdkit: debug: bound to IP address <any>:10809 (2 socket(s))

term2$ qemu-io -f raw nbd://localhost:10809/ -r
qemu-io> r 0 1      # wait to hit Enter until right after ^C in term1

term1$ ^C
nbdkit: debug: waiting for running threads to complete

term2$ # hit enter

term1$
nbdkit: file[1]: debug: acquire per-connection request lock
nbdkit: file[1]: debug: pread count=1 offset=0
nbdkit: file[1]: debug: release per-connection request lock
nbdkit: file[1]: debug: close
nbdkit: debug: waited 2s for running threads to complete
nbdkit: debug:
/home/eblake/nbdkit/plugins/file/.libs/nbdkit-file-plugin.so: unload

term2$
qemu-io> r 0 1
read 1/1 bytes at offset 0
1 bytes, 1 ops; 0.0002 sec (4.138 KiB/sec and 4237.2881 ops/sec)

Why does current traffic from the client cause the plugin to be torn
down faster?  Does it matter?

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

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]