[lxc-devel] Probably more of a user list than a devel lis question but ...

[Michael J Coss]

On 5/7/2014 5:33 PM, Serge Hallyn wrote:
> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ 
> says that if /sys is pre-mounted readonly , then systemd will not 
> mount it. But of course if it's empty i could easily see systemd 
> hanging... i defer to our systemd experts for a few more weeks. 
And this seems to be the case when I was effectively exporting the 
host's /sys via my FUSE.  But I need to filter the container's /sys and 
this is where the problem lies.

> Not what I'd expect, as /sys should never be mounted under
> $LXC_ROOTFS_PATH in any namespace.  When I have a lxc.hook.mount
> script look under $LXC_ROOTFS_{MOUNT,PATH}/sys, only MOUNT has
> contents.
Prior to having the hook script, I had a wrapper around lxc-start and in 
that context I mounted my FUSE on the $LXC_ROOTFS_PATH prior to running 
lxc-start.  This "worked" but was exporting the host /sys into the 
container.  I need the filter to be interactive, and on the host, so the 
FUSE daemon needs to be on the host side, but the sysfs instance I need 
is on the other side of the fence :(
>> Second, looking at the mount point of what should be the container's
>> /sys shows an empty directory.  There are two entries in the host
> Looking when and how?  The only valid test for this is to do it from the
> lxc.hook.mount script.  If it's still empty,then you'll need to
> pre-mount /sys (using lxc.mount.auto, lxc.mount.entry, or just by hand
> in your lxc.hook.mount script before mounting the fusefs).
If I type mount, I see two entries: one for the FUSE, and one for the 
sysfs instance.  I had assumed that I could do a ls on the mount point, 
given that mount was showing the mount point was in my namespace.  
However the directory was empty.

My host.mount script is this:

mount -t sysfs sysfs /etc/lxc/<containername>/sys
mount -t shadowsys -o allow_other,defaults /etc/lxc/<containername>/sys 
$LXC_ROOTFS_MOUNT/sys

As I said, after starting the container, on the host, mount(1) reports 
the two mounts.  But it appears that this just false, in that a cat of 
/proc/mounts shows that neither are in fact mounted from the host's 
point of view.  And umount fails for both.  With or without the 
container running.  So obviously mtab is getting messed up.

> Which fusefs are you using?
> _______________________________________________
>
My own.   As it turns out openRC fails as well, but I accessed the 
container via lxc-attach.  And what I see is that the FUSE daemon is 
running in the container namespace but doesn't seem capable of serving 
any files.  I suspect that the issue is that it can't access anything 
from the host side even though it was created with access to the 
directory, /etc/lxc/<containername>/sys, that it is mirroring.  I'll dig 
deeper into what is going on but I suspect that it may simply not be 
possible to make this work the way I envisioned.

-- 
---Michael J Coss