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

Harald Dunkel harald.dunkel at aixigo.de
Thu Jul 23 12:43:16 UTC 2015


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.

> 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
"subdir1/./..", etc., but don't they all point to the same inode
under the same mount point?


Regards
Harri



More information about the lxc-devel mailing list