Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked.

[Steve Dickson <SteveD@redhat.com>]

J. Bruce Fields wrote:
> On Wed, Nov 12, 2008 at 09:20:20AM +1100, NeilBrown wrote:
>> On Wed, November 12, 2008 6:09 am, J. Bruce Fields wrote:
>>> On Tue, Nov 11, 2008 at 09:29:29AM +1100, Neil Brown wrote:
>>>> I have a situation where rpc.gssd appears to not be working.
>>>> Mount attempts which need to communicate with it block.
>>>>
>>>> I've narrowed down the problem to that fact that all realtime signals
>>>> have been blocked.  This means that DNOTIFY_SIGNAL (which is a
>>>> realtime signal) is never delivered, so gssd never rescans the
>>>> rpc_pipe/nfs directory.
>>>>
>>>> I haven't figured out why the signals are blocked yet, but having
>>>> rpc.gssd fail mysteriously in that situation isn't pleasant.
>>>>
>>>> So I wonder what people think of the following patch.  It simply
>>>> unblocks the signal.  Alternately we can check if it is blocked and
>>>> warn - I'm not really sure of the significance of blocking all these
>>>> signals.  Maybe it's wrong to just unblock them.
>>> So we don't know what it is that's doing the blocking?
>> That information has just come to hand.  It seems to be kde.
>> start_kde (or whatever it is called) and all descendants have these
>> signals blocked.  xfce seems to do the same thing.  gnome doesn't.
>>
>> So if you start rpc.gssd from a terminal window while logged in via
>> KDE, it doesn't behave as expected.
> 
> Whoops.  I guess I (stupidly?) didn't realize signal masks where
> inherited across fork.  So we just need to clear the signal mask at the
> very start and we're done?
Neil? Will this work as well? 

This approach seems a bit more straightforward to me... 

steved.