qemu proper has done so for 13 years
(8a7ddc38a60648257dc0645ab4a05b33d6040063), qemu-img and qemu-io have
done so for four years (526eda14a68d5b3596be715505289b541288ef2a).
Ignoring this signal is especially important in qemu-nbd because
otherwise a client can easily take down the qemu-nbd server by dropping
the connection when the server wants to send something, for example:
$ qemu-nbd -x foo -f raw -t null-co:// &
[1] 12726
$ qemu-io -c quit nbd://localhost/bar
can't open device nbd://localhost/bar: No export with name 'bar' available
[1] + 12726 broken pipe qemu-nbd -x foo -f raw -t null-co://
In this case, the client sends an NBD_OPT_ABORT and closes the
connection (because it is not required to wait for a reply), but the
server replies with an NBD_REP_ACK (because it is required to reply).
Signed-off-by: Max Reitz <mre...@redhat.com>
---
I tried to find some other reproducer instead of using a qemu client
(e.g. nping -c 1 --tcp-connect localhost -p 10809, which gives the same
pattern of <FIN-ACK, >PSH-ACK, <RST as qemu-io) but to no avail. This
only results in the write being successful and the next read failing;
interestingly, sendmsg()'s man page states that EPIPE is only returned
when the local end is closed. However, I have not found the NBD server
to close that local end anywhere.
In any case, ignoring SIGPIPE is the right thing to do. We get an EPIPE
anyway, and this is fully sufficient to let us know that the connection
is dead.
---
qemu-nbd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index b7ab86b..b2eeedb 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -580,6 +580,10 @@ int main(int argc, char **argv)
sa_sigterm.sa_handler = termsig_handler;
sigaction(SIGTERM, &sa_sigterm, NULL);
+#ifdef CONFIG_POSIX
+ signal(SIGPIPE, SIG_IGN);
+#endif
+
module_call_init(MODULE_INIT_TRACE);
qcrypto_init(&error_fatal);
--
2.9.4
