🚀 go-pugleaf

I ran across an interesting problem the other day that may interest some
of you (or you may say what a doof!   :-).

We use the automounter extensively in our multi-vendor network.  However,
all of the above just happened on the Sun's - as a matter of fact, the
public domain  amd  program didn't have this problem.

Filesystem /foo on "mach1" is on a seperate disk and exported.  I recently
moved /foo to a "mach2", but did not want to break user's scripts (some
use hard-coded machines names in the path), so I added a symlink from
mach1:/foo -> /nfs/mach2/users/foo.  I made no other changes (in
hindsight, should have unexported mach1:/foo).

Everything worked OK in the network, until someone made a reference to
/nfs/mach1/foo. At that time, the user's window froze (even the clock),
and the load factor started climbing (reached 10+ on a SS2).  Any other
references to /nfs/* locked up that session.  Normal users rlogin'in never
received the login prompt (probably due to the fact that there home
directory was /nfs/"hostname"/...).  However, root was able to login. Kill
& kill -9 AND shutdown to single-user mode failed to halt the automounter,
so a reboot was required.  Note that the mount command DID work.

Of course, a myrid of other factors were going on that obscured this
problem, so it took a few hours to isloate this as the problem.

Bottom line: Looks like you shouldn't export a filesystem that a symlink
to another automounted filesystem (sure, one would never WANT do this, but
I think you can understand why I did it above).

Alek Komarnitsky
komarnit@tramp.colorado.edu

P.S. Except for a few hiccups like this, the automounter is great!