Hi,
On 24 Jun 2008, at 08:38, Ian Kent wrote:
> On Tue, 2008-06-24 at 08:27 +0100, Anton Altaparmakov wrote:
>> On 24 Jun 2008, at 02:08, Jim Carter wrote:
>>> What do people think would be the best way to get the containing map
>>> key
>>> into the program map? Not the key to be translated by the map (in
>>> our
>>> case PWF-HOME1 etc.), but the key that caused the submount to be
>>> created,
>>> or any of the other environment variables of the submount, such as
>>> $USER,
>>> which is probably what you really want to use here.
>>
>> I would have expected the -DNCP_USER= to be created as an environment
>> variable for the program map to find or alternatively to be given on
>> the program map command line. Given a choice the environment
>> variable
>> option would be much nicer and easier to use.
>
> Setting them in the environment is the sensible and easiest thing
> for me
> to do. But setting the macros that are in the lookup table at the time
> of the mount it isn't done at the moment. I think we had a request for
> this some time ago and I made a patch for testing but didn't get any
> feedback so I let it slip.
Ok. I have for testing purposes done the changes you suggested and am
using a file map successfully so we probably will not want/need to use
a program map given the overhead it would impose. Much easier to
regenerate the file map for each user when they log in. We now have:
/etc/auto.master:
/.servers file:/etc/auto.user
/etc/auto.user:
* -fstype=autofs file:/var/run/pwfautomount/auto.&
And /var/run/pwfautomount/auto.<username> is generated when <username>
user logs in and for my user aia21 contains exactly the same content
as before:
PWF-HOME1 -
fstype
=
ncp
,ipserver
=
172.16.3.42
,owner
=
aia21
,uid
=
aia21
,gid
=
aia21
,hard
,nodev
,nosuid
,nfsextras
,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
authcon/aia21 :PWF-HOME1/aia21.Aliases
PWF-HOME2 -
fstype
=
ncp
,ipserver
=
172.16.3.43
,owner
=
aia21
,uid
=
aia21
,gid
=
aia21
,hard
,nodev
,nosuid
,nfsextras
,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
authcon/aia21 :PWF-HOME2/aia21.Aliases
PWF-HOME3 -
fstype
=
ncp
,ipserver
=
172.16.3.44
,owner
=
aia21
,uid
=
aia21
,gid
=
aia21
,hard
,nodev
,nosuid
,nfsextras
,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
authcon/aia21 :PWF-HOME3/aia21.Aliases
PWF-HOME4 -
fstype
=
ncp
,ipserver
=
172.16.3.45
,owner
=
aia21
,uid
=
aia21
,gid
=
aia21
,hard
,nodev
,nosuid
,nfsextras
,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
authcon/aia21 :PWF-HOME4/aia21.Aliases
PWF-SHARED -
fstype
=
ncp
,ipserver
=
172.16.3.8
,owner
=
aia21
,uid
=
aia21
,gid
=
aia21
,hard
,nodev
,nosuid
,nfsextras
,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
authcon/aia21 :PWF-SHARED/aia21.Aliases
On logout I then do this:
# Kill user's processes politely at first, then less so.
su -c "kill -TERM -1" $user
sleep 1
su -c "kill -KILL -1" $user
sleep 1
# For logging purposes
ps -U $user
# Tidy up the user's (auto)mounts.
(
umount /home/$user
umount /authcon/$user
/sbin/killproc -USR1 /usr/sbin/automount
) >/dev/null 2>&1
And yes, this does expire everybody's non-busy mounts but that is not
actually a bad thing. They will get automounted on next use so there
is no problem. And it has the nice side effect that it will cause
broken mounts to expire sooner. (We have a recurring problem where
people leaving themselves logged in for ages end up with broken
connections and NCPfs does not support reconnects so this might
actually help us.)
>>> Warning: before deploying a submount-based scheme in production,
>>> watch for
>>> a resolution of the internal locking (mutex) issue that's so
>>> bedeviling me.
>>
>> Could you elaborate on this? What issue are you seeing? Thanks a
>> lot
>> in advance!
>
> Jim sees autofs hang.
> There is synchronization problem between submounts that are shutting
> down at the same time a mount request comes in. Of course we only
> see it
> on busy systems.
I assume someone has attached to such a hung machine with gdb and
gotten the two (or more) stack traces involved in the dead lock to
find where in the code this happens? If not, that begs the question
as to why not? (-: Also if the problem really is with a mutex then
the kernel's own mutex debugging code should pick up on the dead lock
and produce stack traces, too. Jim, have you tried running a kernel
with lock debugging features turned on?
If there is a reproducible test case, perhaps a script that can be run
to trigger it, I could look into it if no-one else has done it
already...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
