Re: [PATCH] rpc.idmapd dies with 'I/O possible'

[Luca Giuzzi <luca.giuzzi@gmail.com>]

On Mon, May 16, 2011 at 4:23 PM, Steve Dickson <SteveD@redhat.com> wrote:

> I just updated the bz with these questions, but we can have the
> conversation here...
>
> I'm just a bit concerned by the fact that there are
> a couple of places that sets F_SETSIG and then sets F_NOTIFY,
> so does that mean those places are potential race cases as
> well?
>
where does this happen? There are 3 places where I have seen these fcntl's.
The first three are:
1. in idmapd.c, at nfsopen()
2. in gssd_proc.c at process_clnt_dir()
3. in gssd_main_loop.c at topdirs_add_entry()
In all of these cases, the pattern is to set the SETSIG to something useful, and
then enable NOTIFY, though; thus they should not determine a race.
[there is also a fourth one in idmapd, where the signals are actually
initialized (lines 357-360); however, in the case of failure of the
first SETSIG the daemon does not start]

> Also, after you applied this patch, did the problem go away?

I honestly don't know: the problem seems to have disappeared, in the
sense that the patched daemon has not died. However, before it
occurred with quite a random
pattern (usually, once per day per machine, but it really depended) so
I cannot be sure (it might be it was also related to the overall load
- unfortunately I do not
have the proper statistics).


best,
 lg