From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Dickson Subject: Re: [PATCH] gssd: unblock DNOTIFY_SIGNAL in case it was blocked. Date: Tue, 25 Nov 2008 10:00:09 -0500 Message-ID: <492C12F9.8010309@RedHat.com> References: <18712.46537.9006.490726@notabene.brown> <20081111190940.GA8775@fieldses.org> <20081113043745.GB3098@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: "J. Bruce Fields" , kwc@citi.umich.edu, linux-nfs@vger.kernel.org To: NeilBrown Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39159 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbYKYPCa (ORCPT ); Tue, 25 Nov 2008 10:02:30 -0500 In-Reply-To: <20081113043745.GB3098@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: 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.