Bob Proulx schrieb:
This might help. Are you aware of the NFS mount option 'bg'?
bg
If the first NFS mount attempt times out, retry the mount in the
background. After a mount operation is backgrounded, all
subsequent mounts on the same NFS server will be backgrounded
immediately, without first attempting the mount. A missing mount
point is treated as a timeout, to allow for nested NFS mounts.
No, I wasn't. Thanks! After adding the 'bg' option, the NFS mounts work
again. Results depend on ASYNCMOUNTNFS. With ASYNCMOUNTNFS=no, I get
13:26:08 2007: Starting portmap daemon....
13:26:09 2007: mount to NFS server 'spiro' failed.
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.00"
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.01"
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.02"
The volumes get mounted eventually, but too late for a program that is
started later during the init process and wants to scan the mounted volumes.
With ASYNCMOUNTNFS=yes, the etch default, I get
13:48:54 2007: Starting portmap daemon...Already running..
13:48:54 2007: Waiting for /var/lib/video.00...done.
13:49:13 2007: Waiting for /var/lib/video.01...done.
13:49:15 2007: Waiting for /var/lib/video.02...done.
and the volumes are mounted right away. So this is what I do now.
Using sync versus async is completely different and unrelated. That
has to do with the protocol used after the clients have mounted.
I guess you are talking about something other than the value of
ASYNCMOUNTNFS, which is what I meant? Sorry, I probably used the wrong
terms.
I'm not quite sure whether to file a big report. In the end its my
initscript that causes the problem. On the other hand, without waking up
server there wouldn't be any mounts at all :-)
Malte
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
