On Mon, 2018-03-05 at 18:46 -0600, Benjamin Marzinski wrote:
>
> This is prety close to what I had in mind. The only things missing,
> that
> I noticed when I was looking at multipathd's signal handling, is
> dealing
> with SIGUSR2 in io_err_stat.c, which it sounds like you have already
>
On Mon, Mar 05, 2018 at 06:28:05PM +0100, Martin Wilck wrote:
> Hello Bart,
>
> On Mon, 2018-03-05 at 16:27 +, Bart Van Assche wrote:
> > On Sat, 2018-03-03 at 01:31 +0100, Martin Wilck wrote:
> > > So, there's no reason not to block them, right? Is it expected
> > > behavior
> > > that a
Hello Bart,
On Mon, 2018-03-05 at 16:27 +, Bart Van Assche wrote:
> On Sat, 2018-03-03 at 01:31 +0100, Martin Wilck wrote:
> > So, there's no reason not to block them, right? Is it expected
> > behavior
> > that a user running 'kill -USR2 $(pidof multipathd)' terminates the
> > process? Why
On Sat, 2018-03-03 at 01:31 +0100, Martin Wilck wrote:
> So, there's no reason not to block them, right? Is it expected behavior
> that a user running 'kill -USR2 $(pidof multipathd)' terminates the
> process? Why do you think these signals should interrupt ppoll()
> although the uxlsnr can't
On Fri, 2018-03-02 at 23:27 +, Bart Van Assche wrote:
> On Sat, 2018-03-03 at 00:16 +0100, Martin Wilck wrote:
> > On Fri, 2018-03-02 at 22:23 +, Bart Van Assche wrote:
> > > On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote:
> > > > On Fri, 2018-03-02 at 21:35 +, Bart Van Assche
On Sat, 2018-03-03 at 00:16 +0100, Martin Wilck wrote:
> On Fri, 2018-03-02 at 22:23 +, Bart Van Assche wrote:
> > On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote:
> > > On Fri, 2018-03-02 at 21:35 +, Bart Van Assche wrote:
> > > > This change looks more complicated to me than
On Fri, 2018-03-02 at 22:23 +, Bart Van Assche wrote:
> On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote:
> > On Fri, 2018-03-02 at 21:35 +, Bart Van Assche wrote:
> > > This change looks more complicated to me than necessary. Have you
> > > considered
> > > to pass an empty signal
On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote:
> On Fri, 2018-03-02 at 21:35 +, Bart Van Assche wrote:
> > This change looks more complicated to me than necessary. Have you
> > considered
> > to pass an empty signal set as the fourth ppoll() argument?
>
> An empty set would mean that
On Fri, 2018-03-02 at 21:35 +, Bart Van Assche wrote:
> On Fri, 2018-03-02 at 22:18 +0100, Martin Wilck wrote:
> > diff --git a/multipathd/main.c b/multipathd/main.c
> > index 61739ac6ea59..85ee9b713d75 100644
> > --- a/multipathd/main.c
> > +++ b/multipathd/main.c
> > @@ -2270,10 +2270,13 @@
On Fri, 2018-03-02 at 22:18 +0100, Martin Wilck wrote:
> diff --git a/multipathd/main.c b/multipathd/main.c
> index 61739ac6ea59..85ee9b713d75 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -2270,10 +2270,13 @@ signal_init(void)
> {
> sigset_t set;
>
> -
On Fri, 2018-03-02 at 14:00 -0600, Benjamin Marzinski wrote:
> But
> in any case, after commit 534ec4c, we are only blocking SIGUSR2 on
> all
> threads, which is the only signal we don't need to block. This means
I can see what you mean. Better like this, maybe?
multipathd is supposed to block
11 matches
Mail list logo
