On Sonntag, 28. M�rz 2004 01:35, Jim Carter wrote: > On Fri, 26 Mar 2004, Rainer Krienke wrote: > > I am looking on the exact format that a executable map has to echo to > > stadout in order to automount something. > > As far as I can tell, it's supposed to send out what would have been in a > "file" map, minus the key and following whitespace. For example, I have an > executable map that creates an appropriate file map and then emits a line > to tell the automounter to create a submount with that map. The script > ends with: > Where did you find the information that the format should be like a filemap without the key? I searched the manuals but the only information I was able to find, was that an executable map has to echo a "map" to stdout. A map would have been the key, then optinal options as well as the server:/filesystem entry. But exactly this does not work. So you are probably right that one should omit the key but its not documented as far as I can see.
> > # This seems to work, but is it correct?
> > --bind -soft,retry=6 / server:/export/user/foo
>
> As I read the man page, it isn't. You need 2 or 3 whitespace separated
> fields. (For the executable map the key has to be omitted, meaning 1 or 2
> fields.) This example has 4 fields. The separate operand "--bind" is
> going to be real hard to make to work, and the isolated slash (converted to
> an out-of-order key in other examples) is not wanted. If the autofs daemon
> were to take the last field as the mount referent and the first field
> (--bind) as the mount options, it might just ignore the middle fields, not
> bothering to reject the line for illegal format.
>
> Are you actually getting bind mounts? I thought the referent had to
> already be mounted before you could do a bind mount, and the "olddir" has
The example I gave was not complete because my focus was on the syntax an
executable map has to echo to stdout and less on a complete example. In
reality there is another autmount map that mounts the parent directory of all
users from the user-server. The map looks like this:
user server:/export/user # Map on /import
So when /import/user is reffered to then the parentdirectory with all users is
mouted below /import/user. The auto.home map from above contains enries like
krienke server:/export/user/krienke
Since server:/export/user on the client machine is already mounted
under /import/user autofs placed a bind mount. Well because of what you said
about the problems specifying --bind as an option in the executable map I
guess in between, that my --bind option did not have any effect it was autofs
itself that did the right thing.
>
> > My problem is that after a while on my real server which uses lots of
> > user automounts like described here after shutting down autofs (switching
> > to single user) I am unable to umount the user filesystem with the users
> > on it since it claims to be busy. But there are no more processes (like
> > automount, nfsd, user processes) that could make it busy. So I suspect
> > that a wrong format of the executable map might confuse the kernel.
>
> I doubt the kernel is confused; more likely there really is a process
> "cd'd" to that directory. Try this (on the machine that refuses to
> unmount) -- I'm using my own homedir as the example of what might have to
> be unmounted.
>
> [root tupelo /tmp/root.jimc 2] fuser -mv /h1/maint/jimc
Yes already did this and the output (in single user mode) is empty.
Nevertheless I cannot umount the filesystem. fuser -v /export/user says,
that there is a kernel mount:
USER PID ACCESS COMMAND
/export/user root kernel mount /export/user
but there are no user processes left. Even lsof /export/user does not echo
anything. Here you can see all processes left:
http://www.uni-koblenz.de/~krienke/tmp/processes.txt
The data lie on an xfs filesystem. Below this there is LVM2 and below LVM2
there is a md software raid and below this a md multipath device and then
finally two hardware raids (connected to the host by fibrechannel via two
fc-switches).
Thanks
Rainer Krienke
--
---------------------------------------------------------------------------
Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022
Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312
Mail: [EMAIL PROTECTED], Web: http://www.uni-koblenz.de/~krienke
Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html
---------------------------------------------------------------------------
pgp00000.pgp
Description: signature
_______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
