Steven Hartland wrote:
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the network enough time to
initialise before running. The first error displayed
is:
Mounting NFS file systems:mount_nfs: nfs1: hostname nor
Steven Hartland wrote:
Doug Barton wrote:
Steven Hartland wrote:
Given that it sounds like a potential workaround is to use the
machines IP instead of name until this is fixed, thanks for the info
guys.
For as long as I can remember, it's been a Best Practice to have
Oliver Fromme wrote:
For FreeBSD, I think a workable solution would be to
write a new RC script (e.g. /etc/rc.d/port_up) that
polls the configured interfaces and waits until they
are up. It should have a configurable timeout so it
won't hang forever. Then add it to the REQUIRE line
of the
Steven Hartland wrote:
Oliver Fromme wrote:
For FreeBSD, I think a workable solution would be to
write a new RC script (e.g. /etc/rc.d/port_up) that
polls the configured interfaces and waits until they
are up. It should have a configurable timeout so it
won't hang forever. Then
Steven Hartland wrote:
Although that sounds like a possible solution I wouldnt
be suprised if there are other services which REQUIRE
NETWORKING and make assumptions about the network
state which are currently invalid.
Given this perhaps NETWORKING is where this fix should
really be
Mike Meyer wrote:
No, it will fail immediately (as seen above) if it can't resolve the
server name. The only way to fix this is to modify mount_nfs to
sleep and retry in such cases. The *current* sleep-and-retry code
is in the NFS mount code in the kernel, which doesn't come into play
until
Steven Hartland wrote:
Given that it sounds like a potential workaround is to use the machines
IP instead of name until this is fixed, thanks for the info guys.
For as long as I can remember, it's been a Best Practice to have
entries for critical NFS servers in /etc/hosts.
Doug
--
Doug Barton wrote:
Steven Hartland wrote:
Given that it sounds like a potential workaround is to use the
machines IP instead of name until this is fixed, thanks for the info
guys.
For as long as I can remember, it's been a Best Practice to have
entries for critical NFS servers in
Mike Meyer [EMAIL PROTECTED] writes:
Steven Hartland [EMAIL PROTECTED] writes:
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the network enough time to
initialise before running. The first error displayed
In [EMAIL PROTECTED], Dag-Erling Smørgrav [EMAIL PROTECTED] typed:
Mike Meyer [EMAIL PROTECTED] writes:
Steven Hartland [EMAIL PROTECTED] writes:
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the
Mike Meyer [EMAIL PROTECTED] writes:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
How about an extra flag in your fstab? The default behavior for
mount_nfs is to keep retrying until the mount succeeds.
No, it will fail immediately (as seen above)
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the network enough time to
initialise before running. The first error displayed
is:
Mounting NFS file systems:mount_nfs: nfs1: hostname nor servname provided, or
not
In [EMAIL PROTECTED], Steven Hartland [EMAIL PROTECTED] typed:
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the network enough time to
initialise before running. The first error displayed
is:
Mounting NFS
In the last episode (Mar 02), Steven Hartland said:
Another observation from my recent dealings with using
NFS based /usr is that the remote critical mounts via
nfs dont always give the network enough time to
initialise before running. The first error displayed
is:
Mounting NFS file
14 matches
Mail list logo
