https://bugzilla.novell.com/show_bug.cgi?id=392454
User stvdo@gmx.net added comment
https://bugzilla.novell.com/show_bug.cgi?id=392454#c7
Leuner Heiterbach changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stvdo@gmx.net
--- Comment #7 from Leuner Heiterbach 2008-07-21 02:13:18 MDT ---
Hi,
when searching the database for autofs bugs I came across this bug report which
seems to be caused by the behaviour described below (see also comment
https://bugzilla.novell.com/show_bug.cgi?id=392454#c1).
With the release of openSuse 11.0 I came in touch with nfs-utils version
1.1.2. After configuring a test system for automounting NFS exports from
other machines, logins to the test machine began to take extremely long
(about 2 minutes). I was able to track down the problem to blocking automount
attempts to resources which where exported by the server, but to which the
client test machine had no access permissions. I did an 'strace -p' on the
blocking mount.nfs process and got the following:
..
mount("nfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs",
MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission
denied)
time(NULL) = 1216380212
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({10, 0}, {10, 0}) = 0
mount("nfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs",
MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission
denied)
time(NULL) = 1216380222
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({10, 0}, {10, 0}) = 0
mount("nfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs",
MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission
denied)
..
The access to the NFS resource in question is restricted to certain machines,
i.e. the client test machine is not allowed to mount it. The return value of
EACCES of the mount system call is correct. But as of nfs-utils 1.1.1 this
error qualifies as temporary in mount.nfs so that mount.nfs tries to mount the
resource again and again! From utils/stropts.c:
/*
* Distinguish between permanent and temporary errors.
*
* Returns 0 if the passed-in error is temporary, thus the
* mount system call should be retried; returns one if the
* passed-in error is permanent, thus the mount system call
* should not be retried.
*/
static int is_permanent_error(int error)
{
switch (error) {
case EACCES:
case ESTALE:
case ETIMEDOUT:
case ECONNREFUSED:
return 0; /* temporary */
default:
return 1; /* permanent */
}
}
In case of access restrictions the error should obviously not be considered
temporary and the mount should fail straight away, so that it does not block
subsequent operations. That's how nfs-utils <1.1.1 used to operate.
After patching utils/stropts.c to not qualify EACCES as temporary, the
subsequent mounts worked as expected, i.e. returning immediately if access to
the ressource was denied.
Is this a bug, a conflict with other scenarios of EACCES?
For our setup it is a bug and I have to patch stropts.c.
I saw some discussion about the nfs client having to wait for rebooted servers
which might lead to EACCES during the time window in which the server is not
operational again. But I think mount.nfs should not be guessing about the
state of the server and instead take an access error as a mount failure.
see proposed patch for nfs-utils 1.1.2
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.