autofs hangs when server unavailable

this bugs seems related to bug #214041

... or not, installing nfs-utils 1:1.1.2-4 fixes bug #214041, but not this one. Trying to mount a nfs share of an unavailable host fails after a lengthy delay as described above in hardy with latest updates

today I updated to nfs-common 1:1.1.2-2ubuntu2.2 on my hardy machine but bug is still present: mounting from an unavailable host gives internal error

is still reproducible in jaunty

m4v@lautaro ~ % ping banshee -c1
PING banshee (192.168.1.2) 56(84) bytes of data.
From lautaro (192.168.1.1) icmp_seq=1 Destination Host Unreachable

--- banshee ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

m4v@lautaro ~ % time sudo mount banshee:/home/m4v tmp/mount
mount.nfs: mount system call failed
sudo mount banshee:/home/m4v tmp/mount 0,00s user 0,01s system 0% cpu 1:00,02 total

nfs-common:
  Instalados: 1:1.1.4-1ubuntu1
  Candidato: 1:1.1.4-1ubuntu1
  Tabla de versión:
 *** 1:1.1.4-1ubuntu1 0
        500 http://ar.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Description: Ubuntu jaunty (development branch)
Release: 9.04

I can also confirm this bug in jaunty.
It's the reason why i'm not using autofs at the moment.

The problem is solved by installing the nfs-common version from gutsy.
http://packages.ubuntu.com/gutsy/amd64/nfs-common/download
But i don't think this is a nice sollution.

gutsy is no longer supported so getting nfs-common from packages.ubuntu.com isn't posible.

Did any maintainers/devs ever looked at this? it isn't hard to test yet nobody has even marked it as confirmed.

I've uploaded the gutsy 64 bit version.

I have marked bug #164120 duplicate of this one.

Siegfried De Bie, I will test the package and report back if the issue is fixed with my setup.

kind regards

This can be fixed by not using a hardmount in /etc/fstab. If you add the "soft" option to your mount parameters, the filesystem remains active. I think this is expected behavior for NFS (hard is default due to possible instability issues with soft mounting).

From man nfs:

      soft / hard Determines the recovery behavior of the NFS client after
                     an NFS request times out. If neither option is speci-
                     fied (or if the hard option is specified), NFS requests
                     are retried indefinitely. If the soft option is speci-
                     fied, then the NFS client fails an NFS request after
                     retrans retransmissions have been sent, causing the NFS
                     client to return an error to the calling application.

                     NB: A so-called "soft" timeout can cause silent data
                     corruption in certain cases. As such, use the soft
                     option only when client responsiveness is more important
                     than data integrity. Using NFS over TCP or increasing
                     the value of the retrans option may mitigate some of the
                     risks of using the soft option.

did you try it? the soft/hard mount options has no effect whatsoever
I believe those options does not apply in this case, when the host isn't available on mount.

Yes, the soft option solves the problem on all of my machines from Hardy to Jaunty (Ubuntu, Xubuntu, and Kubuntu). The file system remains responsive (though slow) even after the server is disconnected, and a simple "sudo umount /mountpoint" returns the file system to a normal state.

Ugh ... wrong bug: My comment addresses bug -> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/164120 and landed here because these two bugs have been mistakenly marked as duplicates.

Bug 164120 address NFS concerns for when the server gets disconnected while the client is connected. Bug 234480 addresses NFS concerns for when the server is unavailable to the client during boot. Please remove the duplication and move my above comments to bug 164120 if possible.

I can reproduce it on Karmic:

DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.10 DISTRIB_CODENAME=karmic DISTRIB_DESCRIPTION="Ubuntu 9.10"

Scenario 1: myserver is powered down:

time mount -t nfs myserver.local:/Images /mnt/myserver
mount.nfs: mount system call failed

real 1m0.008s
user 0m0.004s
sys 0m0.004s

Scenario 2: myserver is powered up, but nfsserver not running

time mount -t nfs myserver.local:/Images /mnt/myserver
mount.nfs: mount to NFS server 'myserver.local:/Images' failed: RPC Error: Program not registered

real 0m0.025s
user 0m0.000s
sys 0m0.012s

I think, mount.nfs should always work like Scenario 2

still present in lucid.

ii nfs-common 1:1.2.0-4ubuntu4 NFS support files common to client and serve
ii nfs-kernel-server 1:1.2.0-4ubuntu4 support for NFS kernel server

Workarround:
If the system hangs waiting for response from the unavailable server, to make the system usable, run from terminal:

   sudo service autofs stop

Given that this bug has hung around for a couple of years without much action, I thought I would have another dig around to see if I could find anything useful.

I eventually came to the conclusion that this is actually a kernel issue. It seems that the Gutsy kernel (2.6.22) returns immediately with a "No route to host" message when the server is unavailable, while the later kernels return after a significant delay with alternative error messages.

I also found this post: http://linux-nfs.org/pipermail/nfsv4/2010-February/012112.html that discusses this issue. It indicates that we might see some improvement in kernel 2.6.33.

I installed kernel 2.6.35 in lucid and I can confirm that this bug seems to be fixed. An attempt to mount an export from a non-existent server produces a "No route to host" message after about 3 seconds.

Status changed to 'Confirmed' because the bug affects multiple users.

I've tried "-soft" option in my auto.nfs file but it doesn't solve the issue.

As Gustavo said, the only way to not hang the system is to use the following command line after a startup :
# sudo service autofs stop

This bug is still persistent in Precise Pangolin.

I use the workaround:

sudo service autofs stop

during startup at the moment but that is quite unsatisfactory.

Any updates on this?

This bug is really annoying.

Is there a log that I could provide to analyze this issue?