Needs to retry connect() when interrupted by a signal
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
librpcsecgss (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Hardy |
Fix Released
|
Medium
|
Steve Langasek |
Bug Description
The daemon rpc.gssd uses the clnttcp_create function from librpcsecgss.so to build authentication connections NFS servers providing Kerberized NFS. If a connect() call is taking a long time, then there is a good chance that a change to the pipefs will cause rpc.gssd to get a signal.
We've provided a patch to upstream, which they've accepted. 0.18 contains the fix. I'll also add the patch here, and look at providing a debdiff that incorporates the patch, if I can wrap my head around CDBS.
This bug impacts users of systems that utilise Kerberised NFS in an environment with automounting. On sufficiently loaded systems, the signal from a new mount may interrupt a connect() in progress for an existing mount being made. This can render NFS in such environments ineffective.
A patch has been provided upstream, which they have incorporated into the released 0.18 version of the software. 0.18-1 is in Debian, and A sync has been requested in #234297
A patch and debdiff are attached to this bug report.
TEST CASE:
Probably a difficult one, you'd need a Kerberised NFS environment to start with, then you'd have put the client mounting shares under load, and make subsequent mount attempts. I think it's fairly non-deterministic, but I'm not the original internal bug submitter, so I don't have first-hand details.
Related branches
description: | updated |
Changed in librpcsecgss: | |
assignee: | nobody → vorlon |
importance: | Undecided → Medium |
status: | New → Triaged |
marking as fixed in intrepid, which has 0.18.