# Unkillable process: vi of NFS mounted file in 7.0-STABLE



## amweeden06 (Mar 3, 2011)

I have a virtual machine called quark running 7.0-STABLE and serving as both an NFS server and NFS client.  It mounts a directory with NFS from another virtual machine called hestia running 8.2-PRERELEASE.  Attempting to open a file within the mounted directory on quark with vi causes the process to hang in such a way that it is unkillable, even with -9.  
Commands associated with the nmh mailer also hang, unkillable, when attempting to open  files in the mounted directory on quark.  However, using vim, ed, emacs, or nano does not  cause a hang when attempting to open a file in the directory.

The problem also occurs when mounting the directory on quark from another virtual machine called zeus running 7.0-RELEASE, but not when exporting to zeus from hestia and attempting the same process.

I am wondering why things are hanging with vi but not with the other editors, and why on  quark but not on zeus.

Here is the tail end of a truss of the vi process before it hangs:

```
pwrite(0x4,0x2833101c,0x2800,0x1f6800,0x0,0x0)   = 10240 (0x2800)
pwrite(0x4,0x2833401c,0x2800,0x1f9000,0x0,0x0)   = 10240 (0x2800)
pwrite(0x4,0x2833701c,0x2800,0x1fb800,0x0,0x100000) = 10240 (0x2800)
pread(0x4,0x2833701c,0x2800,0x2800,0x0,0x28312000) = 10240 (0x2800)
issetugid(0x24,0x0,0x224,0x281ee7f8,0x2832a01c,0x281ee7f8) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|
SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|
SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,
0x0) = 0 (0x0)
stat("/tmp",{mode=drwxrwxrwt ,inode=2,size=20480,blksize=4096}) = 0 (0x0)
open("/tmp/bt.90QCF9rx1q",O_RDWR|O_CREAT|O_EXCL,0600) = 5 (0x5)
unlink("/tmp/bt.90QCF9rx1q")                     = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
fcntl(5,F_SETFD,FD_CLOEXEC)                      = 0 (0x0)
fstat(5,{mode=-rw------- ,inode=353,size=0,blksize=4096}) = 0 (0x0)
fstat(5,{mode=-rw------- ,inode=353,size=0,blksize=4096}) = 0 (0x0)
```

quark's /etc/rc.conf has the following lines (among others) in it:

```
nfs_client_enable="YES"
mountd_enable="YES"
mountd_flags="-rln"
nfs_server_enable="YES"
nfs_server_flags="-t -u -a -n 8"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind_enable="YES"
```

quark's /etc/fstab looks like the following:

```
/dev/da0s1b    none     swap  sw                         0  0
/dev/da0s1a    /        ufs   rw                         1  1
/dev/da0s1e    /tmp     ufs   rw                         2  2
/dev/da0s1f    /usr     ufs   rw,userquota,groupquota    2  2
/dev/da1s1d    /var     ufs   rw,userquota,groupquota    2  2
/dev/da2s1c    /clients ufs   rw,userquota,groupquota    2  2
/dev/acd0      /cdrom   cd9660   ro,noauto               0  0
proc            /proc   procfs  rw      0       0
hestia:/clients /hestia nfs     rw,hard,intr    0       0
```

quark's /etc/exports looks like the following:

```
/clients        -network 192.168.0     -mask 255.255.255.0 -maproot=root -ro
/etc            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
/usr            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
/var            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
```

hestia's /etc/rc.conf has the following lines (among others) in it:

```
nfs_server_enable="YES"
nfs_server_flags="-t -u -h 159.28.230.48 -n 8"
mountd_flags="-rln"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
```

hestia's /etc/fstab has the following lines in it:

```
/dev/ad0s1b             none            swap    sw              0       0
/dev/ad0s1a             /               ufs     rw              1       1
/dev/ad0s1e             /clients                ufs     rw,userquota,groupquota         2       2
/dev/ad0s1d             /var            ufs     rw              2       2
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0
```

hestia's /etc/exports looks like the following:

```
/clients        -network 192.168.0     -mask 255.255.255.0 -maproot=root -ro
/etc            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
/usr            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
/var            -network 192.168.0      -mask 255.255.255.0 -maproot=root -ro
```

zeus has the identical /etc/rc.conf, /etc/exports, and /etc/fstab as quark.

Thanks in advance for any help or pointers.  Please let me what additional information I can provide.


----------



## SirDice (Mar 3, 2011)

It might be due to vi's file locking. NFS is notorious in this respect. Not sure if it's the solution but are rpc_lockd and rpc_statd running on the NFS client too?


----------



## amweeden06 (Mar 3, 2011)

Interestingly, quark is running rpc.lockd, but only as the server:


```
amweeden06@quark:~$ ps auxww | grep lockd
root        7568  0.0  0.1  3188  1488  ??  Ss    2:13PM   0:03.27 rpc.lockd: server (rpc.lockd)
```

Whereas zeus, with the identical /etc/rc.conf as quark, has both server and client running:


```
amweeden06@zeus:~$ ps auxww | grep lockd
root     700  0.0  0.2  3188  1560  ??  Is    7:08PM   0:00.00 rpc.lockd: server (rpc.lockd)
daemon   705  0.0  0.2  3188  1564  ??  I     7:08PM   0:00.00 rpc.lockd: client (rpc.lockd)
```

Does the client get started by something other than /etc/rc.conf?  Is there a way to manually bring up the rpc.lockd client?

Thanks.


----------

