multipathd: handle errors in uxlsnr as fatal
authorMartin Wilck <mwilck@suse.com>
Wed, 21 Mar 2018 09:34:19 +0000 (10:34 +0100)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Tue, 15 May 2018 12:57:32 +0000 (14:57 +0200)
commitee01e841ea29e8efcddef53f3dce5e93d3331f43
treec294c68025c083dbb6e26c8f3a7e9ca404262aab
parent94036e3ee569787e79b4f14937744ce7d70f4808
multipathd: handle errors in uxlsnr as fatal

The ppoll() calls of the uxlsnr thread are vital for proper functioning of
multipathd. If the uxlsnr thread can't open the socket or fails to call ppoll()
for other reasons, quit the daemon. If we don't do that, multipathd may
hang in a state where it can't be terminated any more, because the uxlsnr
thread is responsible for handling all signals. This happens e.g. if
systemd's multipathd.socket is running in and multipathd is started from
outside systemd.

24f2844 "multipathd: fix signal blocking logic" has made this problem more
severe. Before that patch, the signals weren't actually blocked in any thread.
That's not to say 24f2844 was wrong. I still think it's correct, we just
need this one on top.

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