Quoting Harald Dunkel (harald.dun...@aixigo.de): > Hi Serge, > > On 07/22/15 22:55, Serge Hallyn wrote: > > Quoting Harald Dunkel (harald.dun...@aixigo.de): > >> > >> This looks pretty fragile to me. Shouldn't lxc report the same > >> state for both paths, no matter what? > > > > No, because when you start the container, it listens on a > > abstract unix socket, i.e. @/var/lib/lxc/rootw1/command, for > > things like 'what is your init pid'. The lxcpath is a part of > > that path. So when you callously do lxc-ls using a different > > lxcpath than you used for lxc-start, you end up looking for > > a command socket which doesn't exist. > > > > Sorry, but this looks like a self-made problem to me. I wonder > if the abstract socket name needs to contain the "/var/lib/lxc/" > at all? unix(7) states about abstract sockets > > "The name has no connection with filesystem pathnames." > > My suggestion would be to use the "real" lxcpath (resolving > all the symlinks and .. and .) for constructing the abstract > socket name.
Well that's true, perhaps lxc should do a realpath on the lxcpath. Patch for that would be welcome. Note though that if realpath fails, then you should simply take what was given - because it is not required that lxcpath actually exist. > > Since a container named 'lxchost01' could exist and be running > > in 5 different lxcpaths at the same time, we can't really avoid > > this. (that is, it has to be the case that the lxcpath matters) > > > > I am not sure if I got this correctly, but afaics you can specify > only one lxcpath for running lxc-create. At least 4 of the 5 > lxcpaths you mentioned include symbolic links or constructs like Sorry - 5 lxcpaths that I mentioned where? > "subdir1/./..", etc., but don't they all point to the same inode > under the same mount point? No, I have containers named t1 under /var/lib/lxc, /var/lib/lxd/lxc, ~/.local/share/lxc, and maybe /usr/local/var/lib/lxc - they're all different containers. But yeah, regarding symlinks you're right that we could readlink to fix that a bit. That would solve a part of your problem - but it won't help if you do lxc-start -n t1 mv /var/lib/lxc /var/lib/lxcc ln -s /var/lib/lxcc /var/lib/lxc because in that case you'll still be changing *actual* lxcpath. But so long as you don't change the lxcpath for a running container, it will support lxc-start -n t1 ln -s /var/lib/lxc /opt/lxc lxc-ls -P /opt/lxc -f -serge _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel