rpc.idmapd hangs after 'bad type in upcall'

Ash Stirling ashley at mun.ca
Fri May 2 07:59:59 EDT 2008




On 01/05/08 5:25 PM, "Jeff Layton" <jlayton at redhat.com> wrote:

> On Thu, 1 May 2008 15:22:58 -0400
> "Kevin Coffman" <kwc at citi.umich.edu> wrote:
> 
>> On Thu, May 1, 2008 at 2:23 PM, Stirling, Ashley <ashley at mun.ca> wrote:
>>> 
>>> We have recently been experiencing a problem where idmapd will log a 'bad
>>> type in upcall' message and thereafter the nfs server will respond to all
>>> requests with NFS4ERR_DELAY.  Restarting rpc.idmapd returns nfs to a
>>> functioning state.
>>> 
>>> The nfs server is running RedHat Enterprise Linux 4:
>>>   kernel 2.6.9-42
>>>   nfs-utils 1.0.6-80
>>> 
>>> Attached are:
>>>   -  the syslogs around the time of the most recent hang
>>>   -  output from strace of the idmapd daemon
>>>   -  packet capture around the time of idmapd hanging
>>> (user names are blanked out to comply with our privacy policy)
>>> 
>>> 
>>> I don't really know what to look for in the attached logs.  Any assistance
>>> or direction you could provide would be greatly appreciated.
>>> 
>>> Thanks,
>>> - Ash
>> 
>> This version of idmapd doesn't properly handle a zero-length read.  I
>> see this was fixed in nfs-utils-1.0.8.  I think the kernel is stuck
>> waiting for an answer, and idmapd is not sending one.  I don't know if
>> there is a kernel change that doesn't send an empty request.
>> 
>> I'm not sure what your options are for upgrading.
>> 
>> Below is the part of the nfs-utils patch to idmapd to handle the
>> zero-length read:
>> 
>> ---------------------------- utils/idmapd/idmapd.c
>> ----------------------------
>> index 5712edb..158feaf 100644
>> @@ -547,9 +547,10 @@ nfsdcb(int fd, short which, void *data)
>>         if (which != EV_READ)
>>                 goto out;
>> 
>> -       if ((len = read(ic->ic_fd, buf, sizeof(buf))) == -1) {
>> +       if ((len = read(ic->ic_fd, buf, sizeof(buf))) <= 0) {
>>                 idmapd_warnx("nfsdcb: read(%s) failed: errno %d (%s)",
>> -                            ic->ic_path, errno, strerror(errno));
>> +                            ic->ic_path, len?errno:0,
>> +                            len?strerror(errno):"End of File");
>>                 goto out;
>>         }
> 
> 
> Thanks Kevin. Ashley, I recommend opening a BZ (or even better, a RH
> support case) and we'll see if we can get that fixed...
> 
> Thanks,

Kevin, Jeff; thank you both for you help.

I will open an RH support case today.  If I get a resolution through those
channels, I will post back to the list for future googlers.

Thanks again,
- Ash



More information about the NFSv4 mailing list