auto.net gets a key with a path under SLES9.

auto.net gets a key with a path under SLES9.

[Hans Deragon]

Greetings.


   I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). 
I did found a little problem with auto.net.  The original code has:

   key=$1

   However, under SLES9, in my network environment, $key can be of the 
form "server/something[/otherthing]*", which is wrong.  $key should only 
be a server name.  I fixed the problem with:

   key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`

   My fix removes any path after the server name.

   Exactly why automount passes a server name containg some path is 
unclear for me.  But I wanted to report this here.  If other suffer from 
this, you might want to consider some fix like mine (maybe using sed 
which is more standard).

   I have not experienced this under Fedora Core 4 (FC4).


Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz

Re: auto.net gets a key with a path under SLES9.

[Jeff Moyer]

==> Regarding [autofs] auto.net gets a key with a path under SLES9.; Hans Deragon <hans@deragon.biz> adds:

hans> Greetings.  I compiled autofs 4.1.4 for SuSE Linux Enterprise Server
hans> 9 (SLES9). I did found a little problem with auto.net.  The original
hans> code has:

hans>    key=$1

hans>    However, under SLES9, in my network environment, $key can be of
hans> the form "server/something[/otherthing]*", which is wrong.  $key
hans> should only be a server name.  I fixed the problem with:

hans>    key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`

hans>    My fix removes any path after the server name.

hans>    Exactly why automount passes a server name containg some path is
hans> unclear for me.  But I wanted to report this here.  If other suffer
hans> from this, you might want to consider some fix like mine (maybe using
hans> sed which is more standard).

hans>    I have not experienced this under Fedora Core 4 (FC4).

Could you enable debugging and post the logs, here?  You can find
information on how to do that on my people page:

  http://people.redhat.com/jmoyer/

I'll note that this sounds like a kernel bug that was fixed a while back,
but that bug was thought to only trigger when ghosting was enabled.  Even
so, you may want to try something like the attached patch.

Thanks,

Jeff

--- linux-2.4.21/fs/autofs4/root.c.orig	2005-05-31 09:31:16.097321176 -0400
+++ linux-2.4.21/fs/autofs4/root.c	2005-05-31 09:31:19.816755736 -0400
@@ -301,7 +301,14 @@ static int try_to_fill_dentry(struct den
 
 		DPRINTK(("try_to_fill_entry: expire done status=%d\n", status));
 		
-		return 0;
+		/*
+		 * If the directory still exists the mount request must
+		 * continue otherwise it can't be followed at the right
+		 * time during the walk.
+		 */
+		status = d_invalidate(dentry);
+		if (status != -EBUSY)
+			return 0;
 	}
 
 	DPRINTK(("try_to_fill_entry: dentry=%p %.*s ino=%p\n", 

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Mon, 14 Nov 2005, Hans Deragon wrote:

Thanks for reporting this Hans.

> Greetings.
> 
> 
>    I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). 
> I did found a little problem with auto.net.  The original code has:
> 
>    key=$1
> 
>    However, under SLES9, in my network environment, $key can be of the 
> form "server/something[/otherthing]*", which is wrong.  $key should only 
> be a server name.  I fixed the problem with:
> 
>    key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
> 
>    My fix removes any path after the server name.

Interesting. I'm not sure why that's happening either.

> 
>    Exactly why automount passes a server name containg some path is 
> unclear for me.  But I wanted to report this here.  If other suffer from 
> this, you might want to consider some fix like mine (maybe using sed 
> which is more standard).

Yep. Sounds like a good idea.

I'll put it on the queue of stuff for 4.1 so I can do it when I eventually 
get back to it.

Ian

Re: auto.net gets a key with a path under SLES9.

[Jeff Moyer]

==> Regarding Re: [autofs] auto.net gets a key with a path under SLES9.; Ian Kent <raven@themaw.net> adds:

raven> On Mon, 14 Nov 2005, Hans Deragon wrote: Thanks for reporting this
raven> Hans.

>> Greetings.
>> 
>> 
>> I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). I
>> did found a little problem with auto.net.  The original code has:
>> 
>> key=$1
>> 
>> However, under SLES9, in my network environment, $key can be of the form
>> "server/something[/otherthing]*", which is wrong.  $key should only be a
>> server name.  I fixed the problem with:
>> 
>> key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
>> 
>> My fix removes any path after the server name.

raven> Interesting. I'm not sure why that's happening either.

>> Exactly why automount passes a server name containg some path is unclear
>> for me.  But I wanted to report this here.  If other suffer from this,
>> you might want to consider some fix like mine (maybe using sed which is
>> more standard).

raven> Yep. Sounds like a good idea.

raven> I'll put it on the queue of stuff for 4.1 so I can do it when I
raven> eventually get back to it.

Ian, this sounds more like papering over the real problem to me.  Do you
agree?  I'd like to see some debug output.

-Jeff

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Tue, 15 Nov 2005, Jeff Moyer wrote:

> ==> Regarding Re: [autofs] auto.net gets a key with a path under SLES9.; Ian Kent <raven@themaw.net> adds:
> 
> raven> On Mon, 14 Nov 2005, Hans Deragon wrote: Thanks for reporting this
> raven> Hans.
> 
> >> Greetings.
> >> 
> >> 
> >> I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). I
> >> did found a little problem with auto.net.  The original code has:
> >> 
> >> key=$1
> >> 
> >> However, under SLES9, in my network environment, $key can be of the form
> >> "server/something[/otherthing]*", which is wrong.  $key should only be a
> >> server name.  I fixed the problem with:
> >> 
> >> key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
> >> 
> >> My fix removes any path after the server name.
> 
> raven> Interesting. I'm not sure why that's happening either.
> 
> >> Exactly why automount passes a server name containg some path is unclear
> >> for me.  But I wanted to report this here.  If other suffer from this,
> >> you might want to consider some fix like mine (maybe using sed which is
> >> more standard).
> 
> raven> Yep. Sounds like a good idea.
> 
> raven> I'll put it on the queue of stuff for 4.1 so I can do it when I
> raven> eventually get back to it.
> 
> Ian, this sounds more like papering over the real problem to me.  Do you
> agree?  I'd like to see some debug output.

Yep. Absolutely right.

Your post was clearly more useful than what I had to say.

And I agree it is likely one of the issues we have recently investigated.
Perhaps the SuSE folks haven't merged some of the recent kernel patches.

Hans, could you spend a bit of time to get us a debug log please.

Ian

Re: auto.net gets a key with a path under SLES9.

[Hans Deragon]

Ian Kent wrote:
> On Tue, 15 Nov 2005, Jeff Moyer wrote:
> 
> 
>>==> Regarding Re: [autofs] auto.net gets a key with a path under SLES9.; Ian Kent <raven@themaw.net> adds:
>>
>>raven> On Mon, 14 Nov 2005, Hans Deragon wrote: Thanks for reporting this
>>raven> Hans.
>>
>>
>>>>Greetings.
>>>>
>>>>
>>>>I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). I
>>>>did found a little problem with auto.net.  The original code has:
>>>>
>>>>key=$1
>>>>
>>>>However, under SLES9, in my network environment, $key can be of the form
>>>>"server/something[/otherthing]*", which is wrong.  $key should only be a
>>>>server name.  I fixed the problem with:
>>>>
>>>>key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
>>>>
>>>>My fix removes any path after the server name.
>>
>>raven> Interesting. I'm not sure why that's happening either.
>>
>>
>>>>Exactly why automount passes a server name containg some path is unclear
>>>>for me.  But I wanted to report this here.  If other suffer from this,
>>>>you might want to consider some fix like mine (maybe using sed which is
>>>>more standard).
>>
>>raven> Yep. Sounds like a good idea.
>>
>>raven> I'll put it on the queue of stuff for 4.1 so I can do it when I
>>raven> eventually get back to it.
>>
>>Ian, this sounds more like papering over the real problem to me.  Do you
>>agree?  I'd like to see some debug output.
> 
> 
> Yep. Absolutely right.
> 
> Your post was clearly more useful than what I had to say.
> 
> And I agree it is likely one of the issues we have recently investigated.
> Perhaps the SuSE folks haven't merged some of the recent kernel patches.
> 
> Hans, could you spend a bit of time to get us a debug log please.
> 
> Ian

No problem.  Just give me instructions on how to proceed.  I am not that 
familiar with autofs and its code/features.

Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Tue, 15 Nov 2005, Hans Deragon wrote:

> Ian Kent wrote:
> > On Tue, 15 Nov 2005, Jeff Moyer wrote:
> > 
> > 
> > > ==> Regarding Re: [autofs] auto.net gets a key with a path under SLES9.;
> > > Ian Kent <raven@themaw.net> adds:
> > > 
> > > raven> On Mon, 14 Nov 2005, Hans Deragon wrote: Thanks for reporting this
> > > raven> Hans.
> > > 
> > > 
> > > > > Greetings.
> > > > > 
> > > > > 
> > > > > I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). I
> > > > > did found a little problem with auto.net.  The original code has:
> > > > > 
> > > > > key=$1
> > > > > 
> > > > > However, under SLES9, in my network environment, $key can be of the
> > > > > form
> > > > > "server/something[/otherthing]*", which is wrong.  $key should only be
> > > > > a
> > > > > server name.  I fixed the problem with:
> > > > > 
> > > > > key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
> > > > > 
> > > > > My fix removes any path after the server name.
> > > 
> > > raven> Interesting. I'm not sure why that's happening either.
> > > 
> > > 
> > > > > Exactly why automount passes a server name containg some path is
> > > > > unclear
> > > > > for me.  But I wanted to report this here.  If other suffer from this,
> > > > > you might want to consider some fix like mine (maybe using sed which
> > > > > is
> > > > > more standard).
> > > 
> > > raven> Yep. Sounds like a good idea.
> > > 
> > > raven> I'll put it on the queue of stuff for 4.1 so I can do it when I
> > > raven> eventually get back to it.
> > > 
> > > Ian, this sounds more like papering over the real problem to me.  Do you
> > > agree?  I'd like to see some debug output.
> > 
> > 
> > Yep. Absolutely right.
> > 
> > Your post was clearly more useful than what I had to say.
> > 
> > And I agree it is likely one of the issues we have recently investigated.
> > Perhaps the SuSE folks haven't merged some of the recent kernel patches.
> > 
> > Hans, could you spend a bit of time to get us a debug log please.
> > 
> > Ian
> 
> No problem.  Just give me instructions on how to proceed.  I am not that
> familiar with autofs and its code/features.
> 

It is fairly straight forward.
Just add --debug or just -d to the master map entry for the autofs mount 
point you want to collect debug info. for.

If you concerned feel free to replace host names or IP addresses (if any) 
but please keep the trace in tact otherwise.

eg.

/net	/etc/auto.net --debug

Should do the trick.

Ian

Re: auto.net gets a key with a path under SLES9.

[Jeff Moyer]

==> Regarding Re: [autofs] auto.net gets a key with a path under SLES9.; Ian Kent <raven@themaw.net> adds:

raven> On Tue, 15 Nov 2005, Hans Deragon wrote:
>> Ian Kent wrote: > On Tue, 15 Nov 2005, Jeff Moyer wrote:
>> > 
>> > 
>> > > ==> Regarding Re: [autofs] auto.net gets a key with a path under
>> SLES9.; > > Ian Kent <raven@themaw.net> adds:
>> > > 
>> > > raven> On Mon, 14 Nov 2005, Hans Deragon wrote: Thanks for reporting
>> this > > raven> Hans.
>> > > 
>> > > 
>> > > > > Greetings.
>> > > > > 
>> > > > > 
>> > > > > I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9
>> (SLES9). I > > > > did found a little problem with auto.net.  The
>> original code has:
>> > > > > 
>> > > > > key=$1
>> > > > > 
>> > > > > However, under SLES9, in my network environment, $key can be of
>> the > > > > form > > > > "server/something[/otherthing]*", which is
>> wrong.  $key should only be > > > > a > > > > server name.  I fixed the
>> problem with:
>> > > > > 
>> > > > > key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
>> > > > > 
>> > > > > My fix removes any path after the server name.
>> > > 
>> > > raven> Interesting. I'm not sure why that's happening either.
>> > > 
>> > > 
>> > > > > Exactly why automount passes a server name containg some path is
>> > > > > unclear > > > > for me.  But I wanted to report this here.  If
>> other suffer from this, > > > > you might want to consider some fix like
>> mine (maybe using sed which > > > > is > > > > more standard).
>> > > 
>> > > raven> Yep. Sounds like a good idea.
>> > > 
>> > > raven> I'll put it on the queue of stuff for 4.1 so I can do it when
>> I > > raven> eventually get back to it.
>> > > 
>> > > Ian, this sounds more like papering over the real problem to me.  Do
>> you > > agree?  I'd like to see some debug output.
>> > 
>> > 
>> > Yep. Absolutely right.
>> > 
>> > Your post was clearly more useful than what I had to say.
>> > 
>> > And I agree it is likely one of the issues we have recently
>> investigated.  > Perhaps the SuSE folks haven't merged some of the
>> recent kernel patches.
>> > 
>> > Hans, could you spend a bit of time to get us a debug log please.
>> > 
>> > Ian
>> 
>> No problem.  Just give me instructions on how to proceed.  I am not that
>> familiar with autofs and its code/features.
>> 

raven> It is fairly straight forward.  Just add --debug or just -d to the
raven> master map entry for the autofs mount point you want to collect
raven> debug info. for.

raven> If you concerned feel free to replace host names or IP addresses (if
raven> any) but please keep the trace in tact otherwise.

raven> eg.

raven> /net /etc/auto.net --debug

raven> Should do the trick.

And, as I mentioned earlier in this thread, you can find more detailed
instructions on my people page, http://people.redhat.com/jmoyer/.

Most notably, it also contains the steps necessary to make the syslog
daemon actually capture the debug logs.

-Jeff

Re: auto.net gets a key with a path under SLES9.

[Hans Deragon]

Well guys, I cannot reproduce the problem at the moment ($key in 
auto.net contains path).  But I will try in the next few days.  The 
error happened and will surely will reappear.

Stay tuned.

Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz

Re: auto.net gets a key with a path under SLES9.

[Hans Deragon]

[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]

Greetings.


   Well, I successfully reproduced the problem of a path sent to 
auto.net (see below for full description).  Attached, the debug output 
on syslogd.  From what I understand of the syslogd logs, the problem 
occurs before sun_mount() is called.

   What I did was:

   cd /net/asterix  # Everything is ok.  $key=asterix
   cd asteris-07    # Bug:  $key=asterix/asterix-07

   What was passed to auto.net was asterix/asterix-07 at the second 'cd'.

   And there is some confusion.  The directory structure should be:

# pwd
/net/asterix
# ls -l
drwxr-xr-x  4 root root 8192 Jun  1 16:23 asterix-00
drwxr-xr-x  5 root root 8192 Sep 20 09:06 asterix-01
drwxr-xr-x  4 root root 8192 Jun 29  2004 asterix-02
drwxr-xr-x  5 root root 8192 Feb 13  2004 asterix-03
drwxr-xr-x  4 root root 8192 Oct 17 07:18 asterix-04
drwxr-xr-x  4 root root   96 Sep 22 13:29 asterix-05
drwxr-xr-x  4 root root   96 Nov  3  2004 asterix-06
drwxr-xr-x  4 root root   96 Nov  3  2004 asterix-07

However, I notice the following:

# pwd
/net/asterix/asterix-07
# ls -l
drwxr-xr-x  4 root root 8192 Jun  1 16:23 asterix-00
drwxr-xr-x  5 root root 8192 Sep 20 09:06 asterix-01
drwxr-xr-x  4 root root 8192 Jun 29  2004 asterix-02
drwxr-xr-x  5 root root 8192 Feb 13  2004 asterix-03
drwxr-xr-x  4 root root 8192 Oct 17 07:18 asterix-04
drwxr-xr-x  4 root root   96 Sep 22 13:29 asterix-05
drwxr-xr-x  4 root root   96 Nov  3  2004 asterix-06

   This is not right.  The content of /net/asterix/asterix-07 is not 
supposed to be the same as /net/asterix.  Something recursive is going on.

I went so far as:

# cd asterix-07
# pwd
/net/asterix/asterix-07/asterix-07
# cd asterix-07
# pwd
/net/asterix/asterix-07/asterix-07/asterix-07
# cd asterix-07
# pwd
/net/asterix/asterix-07/asterix-07/asterix-07/asterix-07

   You see?  Automount fall in a recursive condition.

   Autofs 4.1.4 was used.  What was running was:

/usr/sbin/automount --debug --ghost --timeout 60 /net program /etc/auto.net

   Let me know if you find something strange in the output.  What I do 
not understand, is the asterix-06 mountpoint.


Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz


Hans Deragon wrote:
> Greetings.
> 
> 
>   I compiled autofs 4.1.4 for SuSE Linux Enterprise Server 9 (SLES9). I 
> did found a little problem with auto.net.  The original code has:
> 
>   key=$1
> 
>   However, under SLES9, in my network environment, $key can be of the 
> form "server/something[/otherthing]*", which is wrong.  $key should only 
> be a server name.  I fixed the problem with:
> 
>   key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
> 
>   My fix removes any path after the server name.
> 
>   Exactly why automount passes a server name containg some path is 
> unclear for me.  But I wanted to report this here.  If other suffer from 
> this, you might want to consider some fix like mine (maybe using sed 
> which is more standard).
> 
>   I have not experienced this under Fedora Core 4 (FC4).
> 
> 
> Best regards,
> Hans Deragon


[-- Attachment #2: autofs.pathprob.log --]
[-- Type: text/x-log, Size: 11364 bytes --]

Nov 25 15:44:28 mysystem automount[31394]: handle_packet: type = 0 
Nov 25 15:44:28 mysystem automount[31394]: handle_packet_missing: token 116, name asterix/asterix-07 
Nov 25 15:44:28 mysystem automount[31394]: attempting to mount entry /net/asterix/asterix-07
Nov 25 15:44:28 mysystem automount[31431]: lookup(program): looking up asterix/asterix-07
Nov 25 15:44:28 mysystem automount[31431]: lookup(program): asterix/asterix-07 -> -fstype=nfs,hard,intr,nodev,nosuid  	/asterix-00 asterix:/asterix-00  	/asterix-01 asterix:/asterix-01  	/asterix-02 asterix:/asterix-02  	/asterix-03 asterix:/asterix-03  	/asterix-04 asterix:/asterix-04  	/asterix-05 asterix:/asterix-05  	/asterix-06 asterix:/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): expanded entry: -fstype=nfs,hard,intr,nodev,nosuid  	/asterix-00 asterix:/asterix-00  	/asterix-01 asterix:/asterix-01  	/asterix-02 asterix:/asterix-02  	/asterix-03 asterix:/asterix-03  	/asterix-04 asterix:/asterix-04  	/asterix-05 asterix:/asterix-05  	/asterix-06 asterix:/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("fstype=nfs,hard,intr,nodev,nosuid") -> fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): gathered options: fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-00") -> /asterix-00
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-00") -> asterix:/asterix-00
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-01") -> /asterix-01
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-01") -> asterix:/asterix-01
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-02") -> /asterix-02
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-02") -> asterix:/asterix-02
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-03") -> /asterix-03
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-03") -> asterix:/asterix-03
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-04") -> /asterix-04
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-04") -> asterix:/asterix-04
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-05") -> /asterix-05
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-05") -> asterix:/asterix-05
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("/asterix-06") -> /asterix-06
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): dequote("asterix:/asterix-06") -> asterix:/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-06 on /asterix-06 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-06, what asterix:/asterix-06, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-06 what=asterix:/asterix-06, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-06 elected asterix:/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-06 /net/asterix/asterix-07/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-06 on /net/asterix/asterix-07/asterix-06
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-05 on /asterix-05 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-05, what asterix:/asterix-05, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-05 what=asterix:/asterix-05, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-05 elected asterix:/asterix-05
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-05
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-05 /net/asterix/asterix-07/asterix-05
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-05 on /net/asterix/asterix-07/asterix-05
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-04 on /asterix-04 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-04, what asterix:/asterix-04, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-04 what=asterix:/asterix-04, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-04 elected asterix:/asterix-04
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-04
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-04 /net/asterix/asterix-07/asterix-04
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-04 on /net/asterix/asterix-07/asterix-04
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-03 on /asterix-03 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-03, what asterix:/asterix-03, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-03 what=asterix:/asterix-03, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-03 elected asterix:/asterix-03
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-03
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-03 /net/asterix/asterix-07/asterix-03
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-03 on /net/asterix/asterix-07/asterix-03
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-02 on /asterix-02 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-02, what asterix:/asterix-02, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-02 what=asterix:/asterix-02, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-02 elected asterix:/asterix-02
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-02
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-02 /net/asterix/asterix-07/asterix-02
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-02 on /net/asterix/asterix-07/asterix-02
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-01 on /asterix-01 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-01, what asterix:/asterix-01, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-01 what=asterix:/asterix-01, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-01 elected asterix:/asterix-01
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-01
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-01 /net/asterix/asterix-07/asterix-01
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-01 on /net/asterix/asterix-07/asterix-01
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): multimount: asterix:/asterix-00 on /asterix-00 with options fstype=nfs,hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: parse(sun): mounting root /net/asterix/asterix-07, mountpoint asterix-00, what asterix:/asterix-00, fstype nfs, options hard,intr,nodev,nosuid 
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): root=/net/asterix/asterix-07 name=asterix-00 what=asterix:/asterix-00, fstype=nfs, options=hard,intr,nodev,nosuid
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): nfs options="hard,intr,nodev,nosuid", nosymlink=0, ro=0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): winner = asterix local = 0
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): from asterix:/asterix-00 elected asterix:/asterix-00
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mkdir_path /net/asterix/asterix-07/asterix-00
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): calling mount -t nfs -s  -o hard,intr,nodev,nosuid asterix:/asterix-00 /net/asterix/asterix-07/asterix-00
Nov 25 15:44:28 mysystem automount[31431]: mount(nfs): mounted asterix:/asterix-00 on /net/asterix/asterix-07/asterix-00
Nov 25 15:44:28 mysystem automount[31394]: handle_child: got pid 31431, sig 0 (0), stat 0 
Nov 25 15:44:28 mysystem automount[31394]: sig_child: found pending iop pid 31431: signalled 0 (sig 0), exit status 0
Nov 25 15:44:28 mysystem automount[31394]: send_ready: token=116 

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Fri, 25 Nov 2005, Hans Deragon wrote:

> Greetings.
> 
> 
>   Well, I successfully reproduced the problem of a path sent to auto.net (see
> below for full description).  Attached, the debug output on syslogd.  From
> what I understand of the syslogd logs, the problem occurs before sun_mount()
> is called.
> 
>   What I did was:
> 
>   cd /net/asterix  # Everything is ok.  $key=asterix
>   cd asteris-07    # Bug:  $key=asterix/asterix-07

Yes. Undoubtably the problem and that will be in the kernel module.

> 
>   What was passed to auto.net was asterix/asterix-07 at the second 'cd'.

I would like to see the output of auto.net run manually and with the 
incorrect key please.

Do you have access to the source for for the kernel you are using so that 
we may check the patch levels?

Ian

Re: auto.net gets a key with a path under SLES9.

[Hans Deragon]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

Ian Kent wrote:
> On Fri, 25 Nov 2005, Hans Deragon wrote:
> 
> 
>>Greetings.
>>
>>
>>  Well, I successfully reproduced the problem of a path sent to auto.net (see
>>below for full description).  Attached, the debug output on syslogd.  From
>>what I understand of the syslogd logs, the problem occurs before sun_mount()
>>is called.
>>
>>  What I did was:
>>
>>  cd /net/asterix  # Everything is ok.  $key=asterix
>>  cd asteris-07    # Bug:  $key=asterix/asterix-07
> 
> 
> Yes. Undoubtably the problem and that will be in the kernel module.
> 
> 
>>  What was passed to auto.net was asterix/asterix-07 at the second 'cd'.
> 
> 
> I would like to see the output of auto.net run manually and with the 
> incorrect key please.
> 
> Do you have access to the source for for the kernel you are using so that 
> we may check the patch levels?
> 
> Ian

Greetings Ian.


   Here is the output of auto.net.

[root@mysystem etc] auto.net asterix/asterix-07
/usr/sbin/showmount: can't get address for asterix/asterix-07
[root@mysystem etc] auto.net asterix
-fstype=nfs,hard,intr,nodev,nosuid \
         /asterix-00 asterix:/asterix-00 \
         /asterix-01 asterix:/asterix-01 \
         /asterix-02 asterix:/asterix-02 \
         /asterix-03 asterix:/asterix-03 \
         /asterix-04 asterix:/asterix-04 \
         /asterix-05 asterix:/asterix-05 \
         /asterix-06 asterix:/asterix-06

   Please note that in my previous email, when I reproduced
   the problem, I used a patched auto.net which would remove
   the path.  This is not the case above, since I wanted to
   reproduce the problem for you.

   This said, I just realized that the recursive path problem
   occurs when I try to 'cd' to an NFS share that does not
   exist (I have not realized this earlier; my bad).  For
   instance, with my patched auto.net,
   /net/asterix/asterix-07 mounts with the content of
   /net/asterix, which is wrong.  It should not mount.

   So I am starting to realize that maybe there is no bug...
   If I leave auto.net untouched, I do get the proper error,
   i.e.:

   [root@mysystem /net/asterix] cd asterix-07
   -bash: cd: asterix-07: No such file or directory

   Yet... I think that auto.net should not receive a path.
   So there might be a bug, but a minor one?

   I would need to find a case where a path is sent to
   auto.net when trying to access a valid NFS share.

   Attached, the auto.net, unpatched (actually, my patch is
   commented out).

   Also, I do have the kernel's source.


Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz

[-- Attachment #2: auto.net --]
[-- Type: text/plain, Size: 1571 bytes --]

#!/bin/bash

# $Id: auto.net,v 1.8 2005/04/05 13:02:09 raven Exp $

# This file must be executable to work! chmod 755!

# Look at what a host is exporting to determine what we can mount.
# This is very simple, but it appears to work surprisingly well

# Modified by Hans Deragon, 2005/10/26, 12:57 EDT
# key should be only the hostname, but for some reason, this
# script sometimes receives an NFS share in the form <hostname>/<path>,
# which is wrong.
#echo $1 >>/tmp/auto.net.out
#key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
key=$1  # Original code

# add "nosymlink" here if you want to suppress symlinking local filesystems
# add "nonstrict" to make it OK for some filesystems to not mount
opts="-fstype=nfs,hard,intr,nodev,nosuid"

# Showmount comes in a number of names and varieties.  "showmount" is
# typically an older version which accepts the '--no-headers' flag
# but ignores it.  "kshowmount" is the newer version installed with knfsd,
# which both accepts and acts on the '--no-headers' flag.
#SHOWMOUNT="kshowmount --no-headers -e $key"
#SHOWMOUNT="showmount -e $key | tail -n +2"

for P in /bin /sbin /usr/bin /usr/sbin
do
	for M in showmount kshowmount
	do
		if [ -x $P/$M ]
		then
			SMNT=$P/$M
			break
		fi
	done
done

[ -x $SMNT ] || exit 1

# Newer distributions get this right
SHOWMOUNT="$SMNT --no-headers -e $key"

$SHOWMOUNT | LC_ALL=C sort +0 | \
	awk -v key="$key" -v opts="$opts" -- '
	BEGIN	{ ORS=""; first=1 }
		{ if (first) { print opts; first=0 }; print " \\\n\t" $1, key ":" $1 }
	END	{ if (!first) print "\n"; else exit 1 }
	'

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: auto.net gets a key with a path under SLES9.

[Hans Deragon]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

Resending this email since it seams not to have made it to the mailing list.

-Hans

-------------------------->

Ian Kent wrote:
> On Fri, 25 Nov 2005, Hans Deragon wrote:
> 
> 
>>Greetings.
>>
>>
>>  Well, I successfully reproduced the problem of a path sent to auto.net (see
>>below for full description).  Attached, the debug output on syslogd.  From
>>what I understand of the syslogd logs, the problem occurs before sun_mount()
>>is called.
>>
>>  What I did was:
>>
>>  cd /net/asterix  # Everything is ok.  $key=asterix
>>  cd asteris-07    # Bug:  $key=asterix/asterix-07
> 
> 
> Yes. Undoubtably the problem and that will be in the kernel module.
> 
> 
>>  What was passed to auto.net was asterix/asterix-07 at the second 'cd'.
> 
> 
> I would like to see the output of auto.net run manually and with the 
> incorrect key please.
> 
> Do you have access to the source for for the kernel you are using so that 
> we may check the patch levels?
> 
> Ian

Greetings Ian.


    Here is the output of auto.net.

[root@mysystem etc] auto.net asterix/asterix-07
/usr/sbin/showmount: can't get address for asterix/asterix-07
[root@mysystem etc] auto.net asterix
-fstype=nfs,hard,intr,nodev,nosuid \
          /asterix-00 asterix:/asterix-00 \
          /asterix-01 asterix:/asterix-01 \
          /asterix-02 asterix:/asterix-02 \
          /asterix-03 asterix:/asterix-03 \
          /asterix-04 asterix:/asterix-04 \
          /asterix-05 asterix:/asterix-05 \
          /asterix-06 asterix:/asterix-06

    Please note that in my previous email, when I reproduced
    the problem, I used a patched auto.net which would remove
    the path.  This is not the case above, since I wanted to
    reproduce the problem for you.

    This said, I just realized that the recursive path problem
    occurs when I try to 'cd' to an NFS share that does not
    exist (I have not realized this earlier; my bad).  For
    instance, with my patched auto.net,
    /net/asterix/asterix-07 mounts with the content of
    /net/asterix, which is wrong.  It should not mount.

    So I am starting to realize that maybe there is no bug...
    If I leave auto.net untouched, I do get the proper error,
    i.e.:

    [root@mysystem /net/asterix] cd asterix-07
    -bash: cd: asterix-07: No such file or directory

    Yet... I think that auto.net should not receive a path.
    So there might be a bug, but a minor one?

    I would need to find a case where a path is sent to
    auto.net when trying to access a valid NFS share.

    Attached, the auto.net, unpatched (actually, my patch is
    commented out).

    Also, I do have the kernel's source.


Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.
http://www.deragon.biz        Open source (contribution):
mailto://hans@deragon.biz     http://autopoweroff.deragon.biz


[-- Attachment #2: auto.net --]
[-- Type: text/plain, Size: 1572 bytes --]

#!/bin/bash

# $Id: auto.net,v 1.8 2005/04/05 13:02:09 raven Exp $

# This file must be executable to work! chmod 755!

# Look at what a host is exporting to determine what we can mount.
# This is very simple, but it appears to work surprisingly well

# Modified by Hans Deragon, 2005/10/26, 12:57 EDT
# key should be only the hostname, but for some reason, this
# script sometimes receives an NFS share in the form <hostname>/<path>,
# which is wrong.
#echo $1 >>/tmp/auto.net.out
#key=`echo $1 | perl -wp -e 's%^(\w+)(\/?.+)*$%$1%;'`
key=$1  # Original code

# add "nosymlink" here if you want to suppress symlinking local filesystems
# add "nonstrict" to make it OK for some filesystems to not mount
opts="-fstype=nfs,hard,intr,nodev,nosuid"

# Showmount comes in a number of names and varieties.  "showmount" is
# typically an older version which accepts the '--no-headers' flag
# but ignores it.  "kshowmount" is the newer version installed with knfsd,
# which both accepts and acts on the '--no-headers' flag.
#SHOWMOUNT="kshowmount --no-headers -e $key"
#SHOWMOUNT="showmount -e $key | tail -n +2"

for P in /bin /sbin /usr/bin /usr/sbin
do
	for M in showmount kshowmount
	do
		if [ -x $P/$M ]
		then
			SMNT=$P/$M
			break
		fi
	done
done

[ -x $SMNT ] || exit 1

# Newer distributions get this right
SHOWMOUNT="$SMNT --no-headers -e $key"

$SHOWMOUNT | LC_ALL=C sort +0 | \
	awk -v key="$key" -v opts="$opts" -- '
	BEGIN	{ ORS=""; first=1 }
		{ if (first) { print opts; first=0 }; print " \\\n\t" $1, key ":" $1 }
	END	{ if (!first) print "\n"; else exit 1 }
	'


[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Wed, 30 Nov 2005, Hans Deragon wrote:

> Resending this email since it seams not to have made it to the mailing list.

My bad. Sorry.

> 
> -Hans
> 
> -------------------------->
> 
> Ian Kent wrote:
> > On Fri, 25 Nov 2005, Hans Deragon wrote:
> > 
> > 
> > > Greetings.
> > > 
> > > 
> > >  Well, I successfully reproduced the problem of a path sent to auto.net
> > > (see
> > > below for full description).  Attached, the debug output on syslogd.  From
> > > what I understand of the syslogd logs, the problem occurs before
> > > sun_mount()
> > > is called.
> > > 
> > >  What I did was:
> > > 
> > >  cd /net/asterix  # Everything is ok.  $key=asterix
> > >  cd asteris-07    # Bug:  $key=asterix/asterix-07
> > 
> > 
> > Yes. Undoubtably the problem and that will be in the kernel module.
> > 
> > 
> > >  What was passed to auto.net was asterix/asterix-07 at the second 'cd'.
> > 
> > 
> > I would like to see the output of auto.net run manually and with the
> > incorrect key please.
> > 
> > Do you have access to the source for for the kernel you are using so that we
> > may check the patch levels?
> > 
> > Ian
> 
> Greetings Ian.
> 
> 
>    Here is the output of auto.net.
> 
> [root@mysystem etc] auto.net asterix/asterix-07
> /usr/sbin/showmount: can't get address for asterix/asterix-07
> [root@mysystem etc] auto.net asterix
> -fstype=nfs,hard,intr,nodev,nosuid \
>          /asterix-00 asterix:/asterix-00 \
>          /asterix-01 asterix:/asterix-01 \
>          /asterix-02 asterix:/asterix-02 \
>          /asterix-03 asterix:/asterix-03 \
>          /asterix-04 asterix:/asterix-04 \
>          /asterix-05 asterix:/asterix-05 \
>          /asterix-06 asterix:/asterix-06
> 
>    Please note that in my previous email, when I reproduced
>    the problem, I used a patched auto.net which would remove
>    the path.  This is not the case above, since I wanted to
>    reproduce the problem for you.
> 
>    This said, I just realized that the recursive path problem
>    occurs when I try to 'cd' to an NFS share that does not
>    exist (I have not realized this earlier; my bad).  For
>    instance, with my patched auto.net,
>    /net/asterix/asterix-07 mounts with the content of
>    /net/asterix, which is wrong.  It should not mount.
> 
>    So I am starting to realize that maybe there is no bug...
>    If I leave auto.net untouched, I do get the proper error,
>    i.e.:
> 
>    [root@mysystem /net/asterix] cd asterix-07
>    -bash: cd: asterix-07: No such file or directory
> 
>    Yet... I think that auto.net should not receive a path.
>    So there might be a bug, but a minor one?
> 
>    I would need to find a case where a path is sent to
>    auto.net when trying to access a valid NFS share.
> 
>    Attached, the auto.net, unpatched (actually, my patch is
>    commented out).
> 
>    Also, I do have the kernel's source.
> 
> 
> Best regards,
> Hans Deragon
> --
> Consultant en informatique/Software Consultant
> Deragon Informatique inc.
> http://www.deragon.biz        Open source (contribution):
> mailto://hans@deragon.biz     http://autopoweroff.deragon.biz
> 
> 

Re: auto.net gets a key with a path under SLES9.

[Ian Kent]

On Mon, 28 Nov 2005, Hans Deragon wrote:

> Ian Kent wrote:
> > On Fri, 25 Nov 2005, Hans Deragon wrote:
> > 
> > 
> > > Greetings.
> > > 
> > > 
> > >  Well, I successfully reproduced the problem of a path sent to auto.net
> > > (see
> > > below for full description).  Attached, the debug output on syslogd.  From
> > > what I understand of the syslogd logs, the problem occurs before
> > > sun_mount()
> > > is called.
> > > 
> > >  What I did was:
> > > 
> > >  cd /net/asterix  # Everything is ok.  $key=asterix
> > >  cd asteris-07    # Bug:  $key=asterix/asterix-07
> > 
> > 
> > Yes. Undoubtably the problem and that will be in the kernel module.
> > 
> > 
> > >  What was passed to auto.net was asterix/asterix-07 at the second 'cd'.
> > 
> > 
> > I would like to see the output of auto.net run manually and with the
> > incorrect key please.
> > 
> > Do you have access to the source for for the kernel you are using so that we
> > may check the patch levels?
> > 
> > Ian
> 
> Greetings Ian.
> 
> 
>   Here is the output of auto.net.
> 
> [root@mysystem etc] auto.net asterix/asterix-07
> /usr/sbin/showmount: can't get address for asterix/asterix-07
> [root@mysystem etc] auto.net asterix
> -fstype=nfs,hard,intr,nodev,nosuid \
>         /asterix-00 asterix:/asterix-00 \
>         /asterix-01 asterix:/asterix-01 \
>         /asterix-02 asterix:/asterix-02 \
>         /asterix-03 asterix:/asterix-03 \
>         /asterix-04 asterix:/asterix-04 \
>         /asterix-05 asterix:/asterix-05 \
>         /asterix-06 asterix:/asterix-06
> 
>   Please note that in my previous email, when I reproduced
>   the problem, I used a patched auto.net which would remove
>   the path.  This is not the case above, since I wanted to
>   reproduce the problem for you.
> 
>   This said, I just realized that the recursive path problem
>   occurs when I try to 'cd' to an NFS share that does not
>   exist (I have not realized this earlier; my bad).  For
>   instance, with my patched auto.net,
>   /net/asterix/asterix-07 mounts with the content of
>   /net/asterix, which is wrong.  It should not mount.
> 
>   So I am starting to realize that maybe there is no bug...
>   If I leave auto.net untouched, I do get the proper error,
>   i.e.:
> 
>   [root@mysystem /net/asterix] cd asterix-07
>   -bash: cd: asterix-07: No such file or directory
> 
>   Yet... I think that auto.net should not receive a path.
>   So there might be a bug, but a minor one?

Yep. I think that this may be a known problem.
I need to review and possibly re-test a patch that I've done recently 
before I post it. I suspect that it may have broken the expiry.

> 
>   I would need to find a case where a path is sent to
>   auto.net when trying to access a valid NFS share.
> 
>   Attached, the auto.net, unpatched (actually, my patch is
>   commented out).
> 
>   Also, I do have the kernel's source.

Could you tar the fs/autofs4 directory and send it over so I can check it.
There have been several patches lately and I'd like to confirm which have 
been applied.
 
Ian