On Wed, 2014-01-29 at 17:02 +0100, Donald Buczek wrote: > Hello, > > we are trying to switch from amd to autofs. After successfully testing > and rolling it out to the first several machines, from time to time we > get directories stuck with "Too many levels of symbolic links" on a path > which should be automounted via an indirect map. > > linux 3.8.13 What is linux 3.8.13? Oh right, an old kernel. You need to reproduce this with a current kernel, 3.13.0 for example. OTOH I have had a couple of recent reports of this, not including Leonardo's, so any information is useful. > autofs 5.0.8 > > As an example, here is data from a system where the path /scratch/tmp is > stuck: > > http://www.molgen.mpg.de/~buczek/autofs-demo/ > > auto.master # master map > auto.scratch # indirect map for /scratch > autofs # from /etc/defaults > typescript # shows the problem and a bit of gdb dump of kernel > structures > typescript.l # same with line numbers for reference > gdb-macros # macros used in the gdb session > > From typescript.l , line 122ff it is clear, that /scratch/tmp is not > currently mounted. On the other hand, the gdb session finds the dentry > of /scratch/tmp which has d_flags 0x70080 (line 99,120). This is > DCACHE_MANAGE_TRANSIT+DCACHE_NEED_AUTOMOUNT+DCACHE_MOUNTED+DCACHE_RCUACCESS > with DCACHE_MOUNTED indicating that there should be something mounted > there(?). I think, this state is faulty and necessarily leads to ELOOP > during path walk. Probably the situation is known by the gurus here? Well, at least I believe there's a bug to be found now. >From this output it does show a dentry that, according to the config, shouldn't exist (but might still), is fully visible and claims it's mounted (and definitely should be). > > Is there any known bug which can lead to this situation? Any advice? Any more information you gather would be good. How frequently does this occur? Any idea of the activity leading to this? A full debug log and a time the mount was discovered inoperable might help. > > Thank you > > Donald > -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
