[lxc-devel] symbolic link for /var/lib/lxc

[Serge Hallyn]

Quoting Harald Dunkel (harald.dunkel at aixigo.de):
> Hi Serge,
> 
> On 07/22/15 22:55, Serge Hallyn wrote:
> > Quoting Harald Dunkel (harald.dunkel at 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