[lxc-users] container complains about "too many levels of symbolic links"

[Michael H. Warfield]

On Tue, 2015-07-21 at 13:20 +0200, André Janowicz wrote:
> Hello,
> 
> does anybody know why my containers complain once per
> "lxc.mount.entry"  about  "too many levels of symbolic links"  and
> refuse to start, but then run fine on the  #mountpoints + 1st
> attempt?
> I asked this exact question two weeks ago at stackoverflow in more
> detail but got no answers.  Here's my post:
> 
> http://stackoverflow.com/questions/31266838/why-does-lxc-fail-to-start-because-of-too-many-levels-of-symbolic-links-but-do
> I'm running Ubuntu 14.04 LTS with LXC 1.07 and I'd like to access
> directories from within my lxc-container (ubuntu template) which are
> NFS mounts managed by autofs on the host. 
> 
> Lets say the host has 3 different NFS-shares mounted by autofs:
> 
> auto.vol:
> 
> /vol/server1 -fstype=nfs IPserver1:/vol/server1
> /vol/server2 -fstype=nfs IPserver2:/vol/server2
> /vol/server3 -fstype=nfs IPserver3:/vol/server3
> 
> Now I try to access these from within my container, config looks like
> this:
> 
> lxc.mount.entry = /vol/server1     vol/server1 none bind 0 0
> lxc.mount.entry = /vol/server2     vol/server2 none bind 0 0
> lxc.mount.entry = /vol/server3     vol/server3 none bind 0 0
> 
> Now the problem is this does only work the second or third time I
> start the container, most of the time LXC complains about 'Too many
> levels of symbolic links' and quits. This is the output:
> 
> lxc-start: conf.c: mount_entry: 2049 Too many levels of symbolic links - failed to mount '/vol/server1' on '/usr/lib/x86_64-linux-gnu/lxc/vol/server1'
> lxc-start: conf.c: lxc_setup: 4163 failed to setup the mount entries for 'vm.local'
> lxc-start: start.c: do_start: 688 failed to setup the container
> lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2
> 
> The second time I start the container it complains about /vol/server2
> and so on until it finally works as expected.
> 
> what is the problem and why does it work as I start it more often?

It seems to me (and I use autofs extensively) that you're running into a
race condition with autofs automounting the file systems you want lxc to
then bind mount and they're not coming ready in time.  The reason it
will have worked the second time is that autofs will have had sufficient
time automount the first file system and it's then there but then the
next one isn't so you restart the whole process over again.

Little experiment to try...  For your example above...  Before starting
the container, try this...

ls /vol/server1 /vol/server2 /vol/server3

When that completes, the three file systems will have been automounted
by autofs.  Then immediately start your container.  My guess is that it
will start without a problem.  That would indicate that it is a race
where the bind mounts in lxc are getting ahead of the automounts in
autofs.

I don't know what your trying to accomplish by going through autofs this
way.  Once the container is up, the bind mounts are going to lock autofs
into keeping those file systems mounted.  Wouldn't it make more sense to
just hard mount them before starting the containers?  You would
eliminate autofs periodially checking the mount points to see if they
could be unmounted.  I just don't see what benefit you're deriving from
having autofs in the loop here.

The race condition may be a quirk in the way the bind mounts are
executed by lxc in setting up the container.  If the "ls" hack works,
you could automate this in one of the hook scripts to get the autofs
file systems premounted.

> Thanks in advance,
> 
> 
> André
> 
> 
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150721/f20261ab/attachment.sig>