[NCLUG] autofs behaviour

[Neil Neely]

On Jul 15, 2008, at 10:12 AM, Michael Coffman wrote:

> 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..

Ah well, worth a shot :)

The lopsa discussion went a bit further and one additional  
recommendation was listed that I'll pass along.  The parallel  
discussion is focused on problems with initial mount, not timeout of  
an existing mount so likely the two are unrelated - but on the off  
chance this could help solve your problem I'll pass it along as well:

Neil Neely
http://neil-neely.blogspot.com


On Jul 14, 2008, at 9:16 PM, Theo Van Dinter wrote:

> Try adding "bg" to the mount options.
>
> At work we started having lots of problems after removing the "bg"
> option, since no one was sure why we had it.  Turns out that automount
> was sometimes failing after the first attempt and not retrying in the
> foreground like it was supposed to, but "bg" enabled retrying.   
> Happily,
> automount waits for the mount, even if in the background.  So we  
> added "bg"
> back in as appropriate and things are working again.