AUTOFS doesn't mount directory

[Jean-Guy GROSSE]

It's strange , sometimes autofs doesn't mount the directory :

at 0h14 ? I have a process for write directly to /var/batman/flags.
We have an error : not mounted in fact.

26-Jan 00:14:25 ** ERROR - Flag directory '/var/batman/flags' is not writeable
26-Jan 00:14:25 Killing child processes of pid '9636'.
26-Jan 00:14:25 ** Elapsed Time: 00:00:00 **
26-Jan 00:14:25 *** Finished ***
26-Jan 00:14:25 Initializing object file:

The trace from automout.log :

Jan 25 21:42:56 (thread 1) unmount /var/batman/flags OK
Jan 25 21:42:56 (thread 1) UNMOUNT REPLY : status=0

../..

Jan 26 01:07:11 (thread 15) mount imisgv1:/var/batman/flags OK
Jan 26 01:07:11 (thread 15) MOUNT REPLY : status=0

Only a mount at 1:07 not at 0h14 ....

did you have a similar problem ?

[Peter Godron]

Jean-Guv,
I am not sure on this, but if the directory is unmounted, before you can write it needs to be mounted. The automounter will require a finite amount of time to mount. May be worthwhile trying your write and then retry on failure after a couple of seconds?

[Jean-Guy GROSSE]

Thanks Peter,

What you said it's interresting, but I have a problem now because I changed from automouter to autofs. May be I will come back to the old version.

[Peter Godron]

Jean-Guy,
as a fix would it be possible to leave the mount up permanently?

[Jean-Guy GROSSE]

Yes I know , but for other reasons we prefer to use automounter.
I will check with HP because I read this on
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ENHAUTO

"" Fix to prevent a filesystem from becoming inaccessible under certain circumstances.""

Strange , isn't it ?

Jgg.

[Dave Olker · Accepted solution]

Hello Jean-Guy,

I recently worked on another customer's issue where the Enhanced AutoFS was not mounting a directory when referenced. It turns out the bug was not in the AutoFS code, but in the cp(1) command itself. They were using cp(1) to put files into an AutoFS-managed directory but it would fail if the filesystem wasn't already mounted. The latest cp(1) patch fixed the problem.

I have no idea if your current application uses cp(1) to write to the directory, but if you are able to reproduce this problem we'd definitely be interested in knowing about it because AutoFS should *always* mount up a filesystem it manages when it's referenced.

Also, the idea of "mounting takes a finite amount of time", which I read as implying that if the mounting takes too long the write will fail - doesn't makes sense to me. If you attempt an I/O to a filesystem managed by AutoFS, the I/O attempt will be blocked at the VFS layer waiting for AutoFS to mount the filesystem and return. It's not like the I/O will only wait 10 microseconds and then continue whether the filesystem is there or not. In this case, it seems the I/O never triggers the mount, which is a great concern for AutoFS.

Again, if you can reproduce this problem I strongly urge you to pursue the matter with HP support as we want to get to the bottom of any issue where AutoFS isn't getting triggered by the kernel.

Regards,

Dave

[Jean-Guy GROSSE]

Hello Dave,

Interesting,
In Fact all batches use command > ( It's openfile) not cp command, but of course if i run cd before , it seems better.

I use autoFS in base of HPUXsystem,
I will install Enhanced AUTOFS on the hpux11i test machine and apply same batch during the WE. I will keep you inform if it's better.
I will install :
ENHAUTO B.11.11.0509.1 Enhanced AutoFS, September 2005

Regards,

Jgg.