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

Harald Dunkel harald.dunkel at aixigo.de
Thu Jul 23 14:30:52 UTC 2015


Hi Serge,

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

I never tried that. If the target for lxcpath is optional, then
what is $lxcpath needed for, besides creating 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
> 
> Sorry - 5 lxcpaths that I mentioned where?
> 

A few lines above: "5 different lxcpaths at the same time". This
is just a single container "lxchost01", right?

>> "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.
> 

Sure, but these are *several* containers, each with their own socket.
Very important feature.

> 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
> 

I wouldn't dare to do this.

Another problem not mentioned before is a bind mount of an lxcpath
to another point in the filesystem. This would be very hard to detect.


Regards
Harri



More information about the lxc-devel mailing list