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. > 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 _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
