bin/117603: [patch] dump(8) hangs on SMP - 4way and higher.

[Ian Dowse]

In message <E1IoyTE-0004u8-HK at cs1.cs.huji.ac.il>, Danny Braniss writes:
>I didn't get your 2nd. message, but i'm now looking at the pr :-)
>what if after
>	sigemptyset(&mask);
>we add
>	sigaddset(&mask, SIGUSR2);
>the sigsupend() should only return iff a SIGUSR2 was received.
>would'nt that solve the ^T et.all issue?

I think you'd need to use sigfillset() + sigdelset() instead, but
this would obviously block all other signals, which quite possibly
has unwanted side-effects. E.g. would the slave processes get left
behind if you interrupted the dump with Ctrl-C?

>at the moment only one host has this problem, and it's very unsettling, since
>I can't reproduce it on another similar host. On the other hand someone else
>reported the same issue, and my fix worked for him too.
>Anyways, I see no harm in a little cleanup/upgrade :-)
>also, my feeling is that the problem might be in the kernel, but I got lost
>following the code.

It's important to track down the actual cause of this, especially
if it is a kernel bug. Have you tried the version of the patch I
gave you yet? Its use of the "while (!caught)" loop should in theory
help to narrow down whether this is a race condition or some other
kind of signal loss problem. Also, further details would be helpful,
such as whether the issue generally happens as dump is starting up
or if it can happen after many megabytes of data have been written.

Ian