autofs hangs when server unavailable

Bug #234480 reported by Mal on 2008-05-24
This bug affects 15 people
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)

Bug Description

Binary package hint: nfs-common

When using autofs in Hardy to automount nfs shares, lengthy hangs occur if the target server is not available. This causes nautilus (and the desktop) to hang at login and when opening. The problem seems to originate with changed behaviour of mount.nfs. When attempting to mount a non-existent server export, Gutsy returns in about 3 seconds with the "No route to host" message, Hardy takes about 40 seconds and returns an "internal error". This results in lengthy delays if there are multiple autofs connections to be attempted. These behaviours are shown below:

me@client:~$ cat /etc/*-release
me@client:~$ uname -a
Linux client 2.6.24-16-386 #1 Thu Apr 10 12:50:06 UTC 2008 i686 GNU/Linux
me@client:~$ apt-cache policy nfs-common
  Installed: 1:1.1.2-2ubuntu2.1
  Candidate: 1:1.1.2-2ubuntu2.1
  Version table:
 *** 1:1.1.2-2ubuntu2.1 0
        500 hardy-updates/main Packages
        100 /var/lib/dpkg/status
     1:1.1.2-2ubuntu2 0
        500 hardy/main Packages

me@client:~$ time sudo mount.nfs server:/media/share /media/test -v
[sudo] password for me:
mount.nfs: timeout set for Sat May 24 09:51:29 2008
mount.nfs: text-based options: 'addr='
mount.nfs: internal error

real 0m40.128s
user 0m0.028s
sys 0m0.000s

me@client:~$ cat /etc/*-release
me@client:~$ uname -a
Linux client 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
me@client:~$ apt-cache policy nfs-common
  Installed: 1:1.1.1~git-20070709-3ubuntu1
  Candidate: 1:1.1.1~git-20070709-3ubuntu1
  Version table:
 *** 1:1.1.1~git-20070709-3ubuntu1 0
        500 gutsy/main Packages
        100 /var/lib/dpkg/status

me@client:~$ time sudo mount.nfs server:/media/share /media/test/ -v
[sudo] password for me:

mount.nfs: Unable to connect to, errno 113 (No route to host)

mount.nfs: mount to NFS server 'compaq' failed: System Error: No route to host

real 0m3.006s
user 0m0.000s
sys 0m0.004s


m4v (m4v) wrote :

this bugs seems related to bug #214041

m4v (m4v) wrote :

... 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

m4v (m4v) wrote :

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

m4v (m4v) wrote :

is still reproducible in jaunty

m4v@lautaro ~ % ping banshee -c1
PING banshee ( 56(84) bytes of data.
From lautaro ( 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

  Instalados: 1:1.1.4-1ubuntu1
  Candidato: 1:1.1.4-1ubuntu1
  Tabla de versión:
 *** 1:1.1.4-1ubuntu1 0
        500 jaunty/main Packages
        100 /var/lib/dpkg/status

Description: Ubuntu jaunty (development branch)
Release: 9.04

Siegie (siegie) wrote :

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

Siegie (siegie) wrote :

The problem is solved by installing the nfs-common version from gutsy.
But i don't think this is a nice sollution.

m4v (m4v) wrote :

gutsy is no longer supported so getting nfs-common from 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.

Siegie (siegie) wrote :

I've uploaded the gutsy 64 bit version.

Antoine Pairet (b-ly) wrote :

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

dmizer (dmizer) wrote :

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.

m4v (m4v) wrote :

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.

dmizer (dmizer) wrote :

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.

dmizer (dmizer) wrote :

Ugh ... wrong bug: My comment addresses bug -> 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.

Christoph (chrnag) wrote :

I can reproduce it on Karmic:


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

m4v (m4v) wrote :

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

Gustavo Spadari (gspadari) wrote :

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

   sudo service autofs stop

Mal (mal-gamble) wrote :

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: that discusses this issue. It indicates that we might see some improvement in kernel 2.6.33.

Mal (mal-gamble) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in nfs-utils (Ubuntu):
status: New → Confirmed
boulayj (boulayj) wrote :

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

Thomas Kregelin (tkr) wrote :

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?

Thomas Kregelin (tkr) wrote :

This bug is really annoying.

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers