multipathd: fix client response for socket activation
authorMartin Wilck <mwilck@suse.com>
Tue, 30 Apr 2019 22:41:38 +0000 (00:41 +0200)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Wed, 3 Jul 2019 06:00:26 +0000 (08:00 +0200)
commitcfc6a894ed115841b907d6f0feb0a8f031c323e6
tree60e6d173d5e1f4b31a3340e3dce588274191fe8f
parentbe990cc7a7a169de2185430d23e464506c99f8f3
multipathd: fix client response for socket activation

When a client wakes up multipathd through the socket, it is likely that the
ux listener responds to client requests before multipathd startup has
completed. This means that client commands such as "show paths" or "show
topology" return success with an empty result, which is quite confusing.

Therefore, in the ux listener, don't start answering client requests while
the daemon is configuring. Rather, wait for some other daemon state. We
can't wait hard, because the ux listener must also handle signals. So just
wait for some short time, and poll again.

This has the side effect that command responses for commands that don't
require full initialization, such as "show wildcards", "show config" or
"shutdown", are also delayed until the configuration stage has completed.
But that seems to be a relatively cheap price to pay for getting the
expected response for other commands. To avoid this side effect, the client
handling would need to be rewritten such that the uxlsnr thread would have
a means to "know" which commands require the configuration stage to
complete and which do not.

v2: Removed an unrelated, unnecessary hunk in child().

Signed-off-by: Martin Wilck <mwilck@suse.com>
multipathd/main.c
multipathd/main.h
multipathd/uxlsnr.c