On Tue, Apr 17, 2001 at 03:35:44PM +0100, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Stijn Hoop writes:
> >Now, I know for sure that I only had /usr/ports mounted during the time.
> >And I think it's very strange that the daily security check would fail
> >to mail me when a mount of /usr/ports is failing. Can anyone explain
> >why this would happen? I don't think the security mail should be delayed
> >for a reason like this.
>
> This is well-known and expected NFS behaviour. However, there are
> some NFS mount options that can help. By default, NFS filesystems
> maintain the semantics of local disks; i.e. accesses to them will
> never time out, and are not interruptible, so if an NFS server
> takes week to successfully read file, then the read operation on
> the client will simply take a week to complete. Obviously with
> local disks you rarely see delays this long :-)
Yes, I know that. However, my point was that a hung NFS mount shouldn't
cause the periodic security emails to stall.
> If the "-i" (interruptible) flags is given, then the client will
> still wait forever if a server doesn't respond, but you can interrupt
> the process if you wish. Unless you have a very good reason not to
> want interruptable mounts, you should always specify this to avoid
> unkillable hung processes while the server is down.
Yes, that was my mistake (and probably also that of Gavin Atkinson). It's
also changed now at my client :)
> The "-s" (soft) option is probably what you want. When specified,
> the client will timeout if the server has not responded within a
> reasonable time. Note that doing this can be bad; some applications
> may not be expecting a failure from a supposedly-reliable disk
> operation, so data loss might occur. There are also occasions where
> NFS can get confused, and time out a request when the server is
> alive, but just busy. See the mount_nfs manpage for further details.
That is also good to know. However, my original point still stands. Thanks to
Gavin's email, I understand why it hangs (ie /etc/security traverses nfs
filesystems if they don't have nosuid), but I still want to know if this is
wanted behaviour. It makes it rather easy to shoot yourself in the foot,
since non-interruptible, non-soft mounts are still the default. Any NFS
outage in that case causes all periodic jobs to stall (which is wrong,
IMHO). And in my case, the NFS filesystems are all checked for setuid
changes at the server side, no need to traverse them again on the
client side. This only causes more NFS traffic, with no net gain.
> In general though, NFS only works well when the server is available
> at all times. You may have some success with the "amd" automounter
> which can unmount filesystems that are not in use, but even that
> can result in hung mounts when the server goes away.
Hmm, I could also try that for solving hung NFS mounts - but notice
that /etc/security still searches all suid filesystems.
Thanks for the suggestions though, they still are helpful!
--Stijn
--
Nostalgia ain't what it used to be.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
