autofs reload

autofs reload

["Peter Lojkin"]

Hello,

how to do correct autofs map reload?
with older (3.9.99-4.0.0pre10) autofs updating nis maps works ok.
for example changing in auto.home:
host1:/export/home/user
to
host2:/export/home/user
and doing ls /home/user leads to mounting new users home.

in autofs 4.1.0 (autofs4-20031201 in kernel) it tries to mount host1
even after 5 hours wait and nscd/nis restart.

if i do /etc/init.d/autofs reload it rereads nis maps but starts _new_
automount processes for all maps i.e. i get 2 automount for each map.
after another reload i get 3 etc. and if i understand it correctly they
all try to manage mount points...

if i do /etc/init.d/autofs restart (or stop/start) i get all directories
that were mounted prior to restart empty. all of them are mounted but
ls gives empty directory.

so how to do correct autofs map reload?

Re: autofs reload

[Jeff Moyer]

==> Regarding [autofs] autofs reload; "Peter Lojkin"  <ia6432@inbox.ru> adds:

ia6432> Hello, how to do correct autofs map reload?  with older
ia6432> (3.9.99-4.0.0pre10) autofs updating nis maps works ok.  for example
ia6432> changing in auto.home:
ia6432> host1:/export/home/user
ia6432> to
ia6432> host2:/export/home/user
ia6432> and doing ls /home/user leads to mounting new users home.

ia6432> in autofs 4.1.0 (autofs4-20031201 in kernel) it tries to mount
ia6432> host1 even after 5 hours wait and nscd/nis restart.

Hmm, was the share ever umounted?  You can check this using either lsof of
fuser before you try to do the ls.  If this is the case, your only option
is to kill off users of the mount point and try again.

ia6432> if i do /etc/init.d/autofs reload it rereads nis maps but starts
ia6432> _new_ automount processes for all maps i.e. i get 2 automount for
ia6432> each map.  after another reload i get 3 etc. and if i understand it
ia6432> correctly they all try to manage mount points...

ia6432> if i do /etc/init.d/autofs restart (or stop/start) i get all
ia6432> directories that were mounted prior to restart empty. all of them
ia6432> are mounted but ls gives empty directory.

ia6432> so how to do correct autofs map reload?

Ok, the automount daemon shouldn't start up if the mountpoint is already
controlled by autofs.  Attached is a patch which addresses this.  Comments
welcome.


Cheers,

Jeff

--- autofs-4.1.1/daemon/automount.c.orig	2004-03-18 15:08:30.000000000 -0500
+++ autofs-4.1.1/daemon/automount.c	2004-03-18 15:09:06.000000000 -0500
@@ -388,8 +388,8 @@ static int mount_autofs(char *path)
 	struct stat st;
 	int len;
 
-	if (ap.state != ST_INIT) {
-		/* This can't happen */
+	if ((ap.state != ST_INIT) || is_mounted(path)) {
+		/* This can happen if an autofs process is already running*/
 		error("mount_autofs: already mounted");
 		return -1;
 	}

Re[2]: autofs reload

["Peter Lojkin"]

On Fri, 26 Mar 2004 11:11:46 -0500 at 11:11:46 -0500, Jeff Moyer wrote:

> ia6432> in autofs 4.1.0 (autofs4-20031201 in kernel) it tries to mount
> ia6432> host1 even after 5 hours wait and nscd/nis restart.
> Hmm, was the share ever umounted?  You can check this using either lsof of
> fuser before you try to do the ls.  If this is the case, your only option
> is to kill off users of the mount point and try again.

yes this share was umounted a couple of days prior to auto.home nis map update.

> ia6432> so how to do correct autofs map reload?
> 
> Ok, the automount daemon shouldn't start up if the mountpoint is already
> controlled by autofs.  Attached is a patch which addresses this.
> Comments welcome.
this should fix autofs reload or stop/start? i'll try...

Re: autofs reload

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Lojkin wrote:
| Hello,
|
| how to do correct autofs map reload?
| with older (3.9.99-4.0.0pre10) autofs updating nis maps works ok.
| for example changing in auto.home:
| host1:/export/home/user
| to
| host2:/export/home/user
| and doing ls /home/user leads to mounting new users home.


Ian responded to this a while back, see his answer at:
http://linux.kernel.org/pipermail/autofs/2004-February/000932.html

"That's right because, for file, NIS and LDAP maps, the daemon uses a
cache that is not aware of updates.

In 4.1.0 you can send a HUP signal to the daemon process controling the
map to ask it to update the map in similar fashion to running automount
on Solaris."

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZGFAdQs4kOxk3/MRAiBrAKCFRbar4nWnTcRBPBDw9HlkCfifSACfdVEX
KeLa0I+Ei30gLF9gyQcL0Lc=
=FZyN
-----END PGP SIGNATURE-----

Re: Re[2]: autofs reload

[Jeff Moyer]

==> Regarding Re[2]: [autofs] autofs reload; "Peter Lojkin" <ia6432@inbox.ru> adds:

ia6432> On Fri, 26 Mar 2004 11:11:46 -0500 at 11:11:46 -0500, Jeff Moyer
ia6432> wrote: in autofs 4.1.0 (autofs4-20031201 in kernel) it tries to
ia6432> mount host1 even after 5 hours wait and nscd/nis restart.
>> Hmm, was the share ever umounted?  You can check this using either lsof
>> of fuser before you try to do the ls.  If this is the case, your only
>> option is to kill off users of the mount point and try again.

ia6432> yes this share was umounted a couple of days prior to auto.home nis
ia6432> map update.

What I meant was, at the time you did an ls, were you sure that there were
no applications accessing the directory.  If nothing was accessing the
directory (even if it is mounted), then autofs should be able reload just
fine.  If that's not the case, then I am certainly perplexed.

>> ia6432> so how to do correct autofs map reload?
>> Ok, the automount daemon shouldn't start up if the mountpoint is already
>> controlled by autofs.  Attached is a patch which addresses this.
>> Comments welcome.
ia6432> this should fix autofs reload or stop/start? i'll try...

No, this will prevent the automount daemon from starting more than once for
a given mount point.  Sorry if that was confusing.

-Jeff

Re[4]: autofs reload

["Peter Lojkin"]

On Fri, 26 Mar 2004 at 12:07:58 -0500, Jeff Moyer wrote:

> ia6432> yes this share was umounted a couple of days prior to auto.home nis
> ia6432> map update.
> 
> What I meant was, at the time you did an ls, were you sure that there were
> no applications accessing the directory.
yes there're no applications accessing the directory...

>  If nothing was accessing the
> directory (even if it is mounted), then autofs should be able reload just
> fine.  If that's not the case, then I am certainly perplexed.
looks like it now needs HUP signal to update cache as mentioned in
other rely...

> >> controlled by autofs.  Attached is a patch which addresses this.
> >> Comments welcome.
> ia6432> this should fix autofs reload or stop/start? i'll try...
> 
> No, this will prevent the automount daemon from starting more than once for
> a given mount point.  Sorry if that was confusing.
well it works i.e. no more duplicate automount and it's good.
but now we need to fix "stop" because when i did autofs stop, then
installed new version and did autofs start i got unusable /auto and /home.
with autofs stop all automount processes stoped but autofs on /auto and
/home was not umounted (there're directories in use), so when i started
new version no daemon came up for this points.
then i did umount /auto /home and got several "Busy inodes after unmount".
after next autofs restart everything worked...

Re[2]: autofs reload

["Peter Lojkin"]

On Fri, 26 Mar 2004 at 11:58:41 -0500, Mike Waychison wrote:

> Ian responded to this a while back, see his answer at:
> http://linux.kernel.org/pipermail/autofs/2004-February/000932.html
thanks! missed this one...

> "That's right because, for file, NIS and LDAP maps, the daemon uses a
> cache that is not aware of updates.
> 
> In 4.1.0 you can send a HUP signal to the daemon process controling the
> map to ask it to update the map in similar fashion to running automount
> on Solaris."
then maybe we should do this on autofs reload instead of restarting
daemons?

Re: autofs reload

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Lojkin wrote:
| On Fri, 26 Mar 2004 at 11:58:41 -0500, Mike Waychison wrote:
|
|
|>Ian responded to this a while back, see his answer at:
|>http://linux.kernel.org/pipermail/autofs/2004-February/000932.html
|
| thanks! missed this one...
|
|
|>"That's right because, for file, NIS and LDAP maps, the daemon uses a
|>cache that is not aware of updates.
|>
|>In 4.1.0 you can send a HUP signal to the daemon process controling the
|>map to ask it to update the map in similar fashion to running automount
|>on Solaris."
|
| then maybe we should do this on autofs reload instead of restarting
| daemons?
|

Sure, however doing so will not pick up any changes to the master map :(

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZGmedQs4kOxk3/MRAtaPAJ900FWk/VIKySRwiwtPHyEV/17ejACghZ61
SiCjqCHy86w/ntoX2sztgbg=
=HkPf
-----END PGP SIGNATURE-----

Re: Re[4]: autofs reload

[Jeff Moyer]

==> Regarding Re[4]: [autofs] autofs reload; "Peter Lojkin" <ia6432@inbox.ru> adds:

ia6432> On Fri, 26 Mar 2004 at 12:07:58 -0500, Jeff Moyer wrote: yes this
ia6432> share was umounted a couple of days prior to auto.home nis map
ia6432> update.
>> What I meant was, at the time you did an ls, were you sure that there
>> were no applications accessing the directory.
ia6432> yes there're no applications accessing the directory...

>> If nothing was accessing the directory (even if it is mounted), then
>> autofs should be able reload just fine.  If that's not the case, then I
>> am certainly perplexed.
ia6432> looks like it now needs HUP signal to update cache as mentioned in
ia6432> other rely...

Duh.  Reload only checks for changes in the auto.master file.  Sorry for
the noise.

>> >> controlled by autofs.  Attached is a patch which addresses this.  >>
>> Comments welcome.
ia6432> this should fix autofs reload or stop/start? i'll try...
>> No, this will prevent the automount daemon from starting more than once
>> for a given mount point.  Sorry if that was confusing.
ia6432> well it works i.e. no more duplicate automount and it's good.  but
ia6432> now we need to fix "stop" because when i did autofs stop, then
ia6432> installed new version and did autofs start i got unusable /auto and
ia6432> /home.  with autofs stop all automount processes stoped but autofs
ia6432> on /auto and /home was not umounted (there're directories in use),
ia6432> so when i started new version no daemon came up for this points.
ia6432> then i did umount /auto /home and got several "Busy inodes after
ia6432> unmount".  after next autofs restart everything worked...

Did the script return success when you issued the stop?   My guess is it
just didn't wait long enough for the umount?  Just a guess.

Anyway, I've got some changes to the redhat side of the autofs script to
change the status it prints out (to reflect reality).  Perhaps the attached
patch is worth including?

It may even be beneficial to change autofs reload to send a HUP to all
automount daemons.  Ian, what do you think?

Cheers,

Jeff


--- autofs-4.1.1/samples/rc.autofs.in.init-redhat-only	2004-01-29 11:01:22.000000000 -0500
+++ autofs-4.1.1/samples/rc.autofs.in	2004-03-19 17:41:35.000000000 -0500
@@ -344,7 +336,11 @@
         getmounts | tee $TMP | sh
         RETVAL=$?
 	if [ -s $TMP ] ; then
-	    success "$prog startup" || failure "$prog startup"
+	    if [ $RETVAL -eq 0 ] ; then
+		success "$prog startup"
+	    else
+		failure "$prog startup"
+	    fi
 	    [ $RETVAL = 0 ] && touch /var/lock/subsys/autofs
 	else
 	    echo -n "" $"No Mountpoints Defined"
@@ -356,22 +352,25 @@
   stop)
 	echo -n $"Stopping $prog:"
 	if [ -z "`pidofproc $prog`" -a -z "`getmounts`" ]; then
-		success $"$prog shutdown"
 		RETVAL=0
 	else
 		signal_automounts
 		RETVAL=$?
-		success "$prog shutdown" || failure "$prog shutdown"
 	fi
 	count=0
 	while [ -n "`/sbin/pidof $DAEMON`" -a $count -lt 10 ] ; do
-	   killproc $DAEMON -USR2 2> /dev/null
+	   killproc $DAEMON -USR2 >& /dev/null
 	   RETVAL=$?
 	   [ $RETVAL = 0 -a -z "`/sbin/pidof $DAEMON`" ] || sleep 3
 	   count=`expr $count + 1`
 	done
 	umount -a -f -t autofs
 	rm -f /var/lock/subsys/autofs
+	if [ -n "`/sbin/pidof $DAEMON`" ] ; then
+	    failure "$prog shutdown"
+	else
+	    success "$prog shutdown"
+	fi
 	echo
 	;;
   restart)

Re: autofs reload

[mmarion]

On 26 Mar, Mike Waychison wrote:

> In 4.1.0 you can send a HUP signal to the daemon process controling the
> map to ask it to update the map in similar fashion to running automount
> on Solaris."

BTW, doing that with 4.0.0 (is anyone still running it?) it'll just kill the
daemon.  Found that out the hard way. :-/

I actually wrote a script that runs out of cron every 15 minutes to look for
changes in our auto.home nis map, and only HUP's the daemon if there's a
change, and if the daemon is version >= 4.1.0.  I figure I'd rather not keep
HUP'ing the daemon when there aren't any changes anyway.

-- 
Mike Marion-Unix SysAdmin/Staff Engineer-http://www.qualcomm.com
Bob: "Ok, I'm goin'... but a swift kick in the ass isn't the solution to
everything you know."
Red: "I gotta disagree with you there Bob!" -- That 70's show

Re: Re[4]: autofs reload

[Ian Kent]

On Fri, 26 Mar 2004, Jeff Moyer wrote:

> 
> It may even be beneficial to change autofs reload to send a HUP to all
> automount daemons.  Ian, what do you think?

Oops. My bad. Implemented HUP signal for cached maps but forgot all about 
init script. I'll put together a patch for that and post it. I'm working 
all day today (Saturday) so it won't be till tomorrow.

I see you added that prevent over mount patch to the rpm as well. I like 
that one to I'm going to add it also. I'm guessing that's OK with you 
Jeff.

I'm thinking there will be a 4.1.2 bug fix release soon.

Ian

Re: Re[4]: autofs reload

[Ian Kent]

On Fri, 26 Mar 2004, Jeff Moyer wrote:

> 
> It may even be beneficial to change autofs reload to send a HUP to all
> automount daemons.  Ian, what do you think?
> 

Adding this patch after the previous one should deal with the HUP signal.

diff -Nur autofs-4.1.1.status/samples/rc.autofs.in autofs-4.1.1/samples/rc.autofs.in
--- autofs-4.1.1.status/samples/rc.autofs.in	2004-03-29 17:28:27.000000000 +0800
+++ autofs-4.1.1/samples/rc.autofs.in	2004-03-29 17:28:43.000000000 +0800
@@ -403,6 +403,9 @@
 			kill -USR2 $pid 2> /dev/null
 			echo $"Stop $command"
 		    fi
+		else
+			kill -HUP $pid 2> /dev/null
+			echo $"Reload map $command"
 		fi
 	    done
 	)
@@ -464,6 +467,9 @@
 		then
 			echo "Stopping automounter: $command"
 			kill -USR2 $pid 2> /dev/null
+		else
+			echo "Reloading automounter map: $command"
+			kill -HUP $pid 2> /dev/null
 		fi
 	done
 	rm -f $TMP

Re: autofs reload

[Ryan Go]

On Fri, 26 Mar 2004 mmarion@qualcomm.com wrote:

> On 26 Mar, Mike Waychison wrote:
>
> > In 4.1.0 you can send a HUP signal to the daemon process controling the
> > map to ask it to update the map in similar fashion to running automount
> > on Solaris."
>
> BTW, doing that with 4.0.0 (is anyone still running it?) it'll just kill the
> daemon.  Found that out the hard way. :-/

Yeap. We still are. 4.0.0pre10-x (at least SuSe's version).

>
> I actually wrote a script that runs out of cron every 15 minutes to look for
> changes in our auto.home nis map, and only HUP's the daemon if there's a
> change, and if the daemon is version >= 4.1.0.  I figure I'd rather not keep
> HUP'ing the daemon when there aren't any changes anyway.
>
> --
> Mike Marion-Unix SysAdmin/Staff Engineer-http://www.qualcomm.com
> Bob: "Ok, I'm goin'... but a swift kick in the ass isn't the solution to
> everything you know."
> Red: "I gotta disagree with you there Bob!" -- That 70's show
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>

Re: autofs reload

[Tom Georgoulias]

Ryan Go wrote:

>>BTW, doing that with 4.0.0 (is anyone still running it?) it'll just kill the
>>daemon.  Found that out the hard way. :-/
> 
> 
> Yeap. We still are. 4.0.0pre10-x (at least SuSe's version).

I had considered reverting back to the 4.0.0pre10 version many times 
because it doesn't require me to manually HUP daemons to put map updates 
into effect. Now that some patches are showing up my reversion 
tendencies are reducing.  ;)

I'm glad to see Jeff Moyer posting to the list and submitting patches. 
Good to know that Red Hat is listening to its customers who need more 
than autofs v3.

Tom
-- 
Tom Georgoulias
POPI Classification
[x] General Business Information
[] Motorola Internal Use
[] Motorola Confidential Proprietary