we recently began using the v4 beta and ran into a problem - after using autofs for a
while, we'd run out of mount table slots. after digging into it, i discovered that
there is a bug in /etc/auto.net which, in conjunction with a "feature" in the daemon,
will cause autofs to consume mount table slots until the table is exhausted.
the root problem is that /etc/auto.net *does not* sort the output of showmount
correctly.
this can cause the list of mounts returned by auto.net to have subdirs listed before
ancestor dirs. when that happens, autofs winds up mounting the ancestor over the
descendant, hiding the descendant tree. when a multi-mount with hidden descendants
expires, the unmount of the descendant fails (since the mount is hidden by the
mount of its ancestor). the daemon responds to the unmount failure during an expire
by re-mounting everything in an attempt to put the mulit-mount back into a known state.
but this triggers the problem again! over time, you wind up with a stack of descendant
mounts hidden by one ancestor mount. eventually you run out of mount table slots.
to see the sorting problem, consider the following two files:
File A
======
/a/b/c
/a/b
/a/b/b
File B
======
/a/b/c (everyone)
/a/b (everyone)
/a/b/c (everyone)
after sorting, you get:
File A
======
/a/b
/a/b/b
/a/b/c
File B
======
/a/b/b (everyone)
/a/b/c (everyone)
/a/b (everyone)
why does this happen? you've got me. i've been using unix for twenty years and
the behavior and command line arguments to 'sort' are still mysterious to me :-).
if you drop an "awk {print $1}" between the showmount & the sort commands (you can
remove the "+0" from the sort command), than sort will do the right thing.
thoughts/comments?
/mark kennedy
