[NCLUG] autofs behaviour

[Michael Coffman]

On Mon, 14 Jul 2008, Neil Neely wrote:

> On Jul 11, 2008, at 9:29 AM, Michael Coffman wrote:
>> I have a question about the behaviour of autofs.  It seems like it is
>> very easy to hit a situation where autofs will unmount a file system
>> and an active process will lose access to a file and fail to read it.
>> This seems to happen with both direct and indirect mapping.
>> 
>> Specifics about what I am running:
>>
>>   autofs-4.1.3-199.3
>>   kernel - 2.6.9-55.ELsmp
>>   arch - x86_64
>>   OS - Red Hat Enterprise Linux WS release 4 (Nahant Update 5
>> 
>> autofs is configured to use the defaults and has host mapping
>> enabled.  When I run the following simple test:
>>
>>  date;while [[ -r /net/hostname/test ]]; do :; done; date
>> 
>> command output:
>>  Fri Jul 11 09:02:46 MDT 2008
>>  Fri Jul 11 09:03:59 MDT 2008
>> command output run 2:
>>  Fri Jul 11 09:11:42 MDT 2008
>>  Fri Jul 11 09:12:45 MDT 2008
>> 
>> As you can see, I lose read access typically shortly after the mount is 
>> supposed to time out.
>> 
>> I believe that after the timeout, autofs tries to unmount file systems and 
>> if they are busy, resets the timeout counter and remounts any unmounted 
>> mount points if it is a host map.
>> 
>> But in general, I would think that I should never lose read access to the
>> file.  Shouldn't autofs just remount it if it has been unmounted?
>> 
>> Anyone have any insight?
>> 
>> BTW: am-utils (amd) does not behave this way.  I am guessing this
>>     has to do with the fact that it runs in user space.
>> 
>> -- 
>> -MichaelC
>
>
>
> I'm going to cross-post something from a LOPSA mailing list that may be 
> relevant to this  - at the least I found it interesting so I'm going to share 
> it here.  Short form is that the interaction of autofs and soft mounts 
> creates some quirky behavior that could possibly explain what you are seeing.

Interesting, but I'm not using soft mounts.  Here are the options form 
/proc/mounts for
the file system:

rw,nosuid,nodev,v3,rsize=32768,wsize=32768,hard,intr,tcp,lock,proto=tcp,timeo=600,retrans=5,addr=farmall 
0 0

FWIW - I see the same behaviour with a soft mount..

>
> Neil Neely
> http://neil-neely.blogspot.com
>
>
> Discussion from lopsa-tech mailing list follows:
>
> On Jul 14, 2008, at 4:43 PM, rackow at mcs.anl.gov wrote:
>> How are you doing your mounts?  Are they hard or soft mounts?  From
>> your description, I presume it's a soft mount. This tends to cause
>> these kinds of problems.  With a hard mount, you get a return of
>> true/false on the existance of a file.  With a soft-mount,
>> you get true/false/wait-a-bit.  I know these are not the right
>> terms, but you get the idea.  The problem is that most tools do
>> not understand that 3rd return state, so treat is as a false/failure
>> and strange things happen.  When you retry, the mount has now
>> completed, so you are back to the true/false realm of states.
>> 
>> I've run into more problems with "soft-mounts" because of this
>> that I'll never use them on a system I manage.  While I can
>> see some value in not hanging a system waiting for a mount to
>> complete, it really doesn't overcome the problems it causes
>> with things like this.
>> 
>> -_Gene
>> 
>> 
>> "Derek J. Balling" made the following keystrokes:
>> > I've been seeing this phenomenon for a while now, but can't figure out
>> > what setting I need to tweak to make it not be a problem.
>> > 
>> > We're using autofs/NFS for our home directories on CentOS (RHEL) 5.1.
>> > If I SSH into my home directory (using SSH keys), INITIALLY the key-
>> > use will fail and it will fall back to my password. But then that
>> > attempt to read my keyfile has triggered the NFS mount, and any
>> > subsequent attempts will succeed.
>> > 
>> > Likewise if we try to run shell scripts that are in /mnt/scripts/
>> > foo.sh... the first time we issue the command we'll get a file not
>> > found, and then if we simply hit up-arrow and do it again, it works
>> > fine.
>> > 
>> > It's especially problematic in scripts. I've taken to doing stupid
>> > hacks like:
>> > 
>> > ls /mnt/scripts 2>/dev/null 1>/dev/null ; /mnt/scripts/
>> > scriptName.sh arg1 arg2
>> > 
>> > Just to force the autofs to "fail" on my ls and then have it around
>> > for the script that has to get called.
>> > 
>> > Is there some setting somewhere I need to tweak? Has anyone seen this
>> > before?
>> > 
>> > cheers,
>> > D
>
>
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modifyyour settings, go 
> to:http://www.nclug.org/mailman/listinfo/nclug
>

-- 
-MichaelC