[lxc-users] Mounted /proc entries empty

Serge E. Hallyn serge at hallyn.com
Wed Oct 2 14:23:02 UTC 2019


Hi,

So is that (messages ending up in /var/log/damon.log) because your init
system is redirecting stderr from the startd service to there?

I'm pretty sure fuse sends it's messages to stderr.  If fuse is sending
them elsewhere then we'd want to give a hint about that in the lxcfs
error path.  But if the init system is making that happen then lxcfs
of course can't guess.

-serge

On Wed, Sep 25, 2019 at 07:17:02PM +0100, Ben Green wrote:
> 
> No warning via console, but once I looked in /var/log/daemon.log it was
> obvious what had happened, the usual fuse directory not empty warning
> appeared on service start:
> 
> Sep 25 13:42:12 oyster lxcfs[9748]: fuse: mountpoint is not empty
> Sep 25 13:42:12 oyster lxcfs[9748]: fuse: if you are sure this is safe, use
> the 'nonempty' mount option
> 
> 
> 
> Cheers,
> Ben
> 
> 
> Quoting "Serge E. Hallyn" <serge at hallyn.com>:
> 
> > Hi,
> > 
> > was there no warning at all about that?  We might want to add a message
> > if we detect that condition at startup.
> > 
> > -serge
> > 
> > On Wed, Sep 25, 2019 at 01:56:38PM +0100, Ben Green wrote:
> > > Hi all,
> > > 
> > > sad I didn't get any response at all, but I fixed my problem anyway. It
> > > turns out that lxcfs was unable to mount it's fuse mount on /var/lib/lxcfs
> > > because a file had ended up there, and fuse won't mount if it finds a
> > > non-empty directory. Once I cleared out that directory and restarted lxcfs
> > > it all worked fine.
> > > 
> > > Cheers,
> > > Ben
> > > 
> > > Quoting Ben Green <ben at bristolwireless.net>:
> > > 
> > > > Hi all,
> > > >
> > > > first time writing to this list for me, I checked a few months back
> > > > posts to see if this issue had come up recently.
> > > >
> > > > I've been trying to get some elements of LXC to work on Debian 10
> > > > 'Buster'. One issue is outstanding.
> > > >
> > > > From inside containers the /proc entries that mounted onto it contain
> > > > nothing. They look like this when mounted:
> > > >
> > > > /dev/sda9 on /proc/cpuinfo type ext3 (rw,relatime)
> > > > /dev/sda9 on /proc/diskstats type ext3 (rw,relatime)
> > > > /dev/sda9 on /proc/meminfo type ext3 (rw,relatime)
> > > > /dev/sda9 on /proc/stat type ext3 (rw,relatime)
> > > > /dev/sda9 on /proc/swaps type ext3 (rw,relatime)
> > > > /dev/sda9 on /proc/uptime type ext3 (rw,relatime)
> > > >
> > > >
> > > > I've tried Ubuntu containers, Debian containers and both unprivileged
> > > > and privileged. Here's how one stats:
> > > >
> > > >
> > > > root at bambooz:~# stat /proc/cpuinfo
> > > >   File: /proc/cpuinfo
> > > >   Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
> > > > Device: 809h/2057d	Inode: 16640192    Links: 1
> > > > Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> > > > Access: 2019-09-24 10:12:46.000000000 +0000
> > > > Modify: 2019-09-10 12:27:13.000000000 +0000
> > > > Change: 2019-09-10 12:27:13.000000000 +0000
> > > >  Birth: -
> > > >
> > > >
> > > > That's all I've got. Not seeing anything unusual in the way it boots up.
> > > > I've attached example DEBUG logs for one of the unprivileged guests I've
> > > > tried. Has anyone any clues about what's happening here?
> > > >
> > > >
> > > > Cheers,
> > > > Ben
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > lxc-users mailing list
> > > lxc-users at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users


More information about the lxc-users mailing list