6

I am currently experiencing a bug in Ubuntu 13.10 which means that when I resume my machine after a suspend, the network connections do not come back up. I have a couple of NFS mounts and because they are in a hung state, any time I try to run anything on the command line (eg. the workaround in that bug report: nmcli cli sleep false) the shell hangs. By "hang" I mean they are unresponsive to any signals (Ctrl-C, Ctrl-Z, kill, etc).

When I use absolute paths (ieeg. /usr/bin/nmcli) it runs fine as expected. When I resume the network connection, all the hung processes come back to life and complete their execution.

I'm confused as to why this happens. My current suspicion is that bash is attempting to search in one of the NFS mounted directories for the command I am trying to run. My PATH does not include any of the NFS mounted directories though.

So my question is twofold: Why does the shell hang in this way and how can I stop it?

3
  • 3
    Can you strace -e file a shell, to see which files it tries to access?
    – ninjalj
    Oct 30, 2013 at 10:30
  • When it was hung I ran strace on a bash process and then tried to run something. I didn't spot anything obviously wrong in the output. I'll try file tracing next time it happens. (Also thanks for making me aware of -e!)
    – Burhan Ali
    Oct 30, 2013 at 12:48
  • 1
    So it turns out that one of the directories on my PATH was actually a symlink into one of the NFS mounts. I had forgotten I had done that. strace -e file helped me to identify it, so thanks @ninjalj for adding another tool to my toolbox.
    – Burhan Ali
    Oct 31, 2013 at 9:05

4 Answers 4

3

In my experience the Linux implementation of NFS isn't as sound as that on Solaris. In particular NFS on Linux can cause processes to hang on a device, so you might seem some processes in this state:

[pkearns@centos6 ~]$ ps -lp $$
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 D   500  2626  2307  0  80   0 -  1282 -      pts/1    00:00:00 bash
[pkearns@centos6 ~]$ 

The D in the second column indicating the process is hanging on a device. That device-hanging can propagate through the system in an unpredictable way interfering with seemingly unrelated processes.

Try this:

ps -elf | awk '$2=="D"'

That will show any processes hanging on devices.

2

By default, NFS is using hard, non-interruptible FS calls. Thus, you can't "Ctrl+C" or "Ctrl+Z" any FS operation (may it be a read, write, stat...).

To be able to "Ctrl+C" you can mount your NFS share with the option "intr" to be able to interrupt the syscall. You can test it with : mount -o remount,intr /YOUR/MOUNTPOINT

And after, edit the /etc/fstab file to add the option for persistance.

The "nolock" option is only to disable "File Locking" method, used to avoid concurrent writing by multiple clients. It does nothing to have with the I/O.

For the question "Why does it hang while I don't have any reference to NFS places", maybe there is a thing with bashcompletion, or a script which does use a command that test NFS ?

Adrien.

0

Probably using "-o nolock" option on the client side can solve your problem.

0

Reason for this usually is a process waiting to timeout on the NFS share (which often doesn't happen at all). In shell, the most likely reason is one of the directories in your PATH that comes before the one really containing the executable being on an inaccessible NFS share (which as you have found out was indeed the case)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .