On Fri, 2019-01-04 at 02:25 +, Chongyun Wu wrote:
> Hi Martin,
>
> Yes, I have your patch f1c73962's fix.
> Your patch f1c73962 "multipathd: make DAEMON_SHUTDOWN a terminal
> state"
> is good and needed because I also meet that situation need your patch
> to
> fix, but we also meet another i
From: Chongyun Wu
Test environment: 25 hosts, each host have more than 100 luns,
each lun have two paths.
Some times when we try to ceate new multipath will encounter "could
not create uxsock:98" but the multipathd still running not shutdown
and can't response any multipathd commands also.
After
Hi Chongyun, Ben, all,
this patch set addresses the points where I can see that handling of
shutdown signals may be delayed, as discussed previously. Quoting my
previous post:
Let's summarize how multipathd exit works today:
1. signal arrives
(signal may be blocked while uxlsnr is busy, see
Cancel the other threads before taking vecs->lock. This avoids
delays during shutdown caused e.g. by the checker thread holding
the vecs lock.
Signed-off-by: Martin Wilck
---
multipathd/main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/multipathd/main.c
Chonyun Wu's latest patch has shown that the handling of the daemon
state variable running_state is racy and difficult to get right. It's
not a good candidate for a "benign race" annotation. So, as a first
step to sanitizing it, make sure all accesses to the state variable
are protected by config_l
multipathd blocks all signals except in the uxlsnr thread.
Add some code to handle signals even while they're blocked.
If a shutdown signal is received, deliver_pending_signals() returns
TRUE. This is not the same as should_exit(), it's just a friendly
warning to the caller that shutdown/thread ca
reconfigure() can be a long-running operation; both initial path
discovery and initial map setup can take a long time. Allow
the main program to indicate that the process should be
interrupted if a shutdown signal was received.
Signed-off-by: Martin Wilck
---
libmultipath/configure.c | 5 +
The uxlsnr thread is responsible for receiving and handling
signals in multipathd. This works well while it is idle and
waiting for connections in ppoll(). But if it's busy, cli commands
may need to take the vecs lock, which might take a long time.
Use multipathd's ability to handle pending signal
