I’m having some issues with lxc and application containers since upgrading to 12.3. Things worked fine with 12.2.
Environment:
OpenSuse 12.3
Linux 3.9.0-2-desktop
and Linux 3.7.10-1.1-desktop
lxc 0.8.0-3.8.1
Trying to run an application container fails, either as user or root:
$lxc-execute -n temp1 -- 'top'
lxc-execute: No such file or directory - failed to create symlink for kmsg
lxc-execute: failed to setup kmsg for 'temp1'
lxc-execute: failed to setup the container
lxc-execute: invalid sequence number 1. expected 2
lxc-execute: failed to spawn 'temp1'
lxc-init is prsent:
# ls -ld /usr/lib/lxc/lxc-init -rwxr-xr-x 1 root root 10768 Mar 1 03:22 /usr/lib/lxc/lxc-init
I’ve never had any issue using numeric valunes in container names. Regardless of that though, this should work to start an application container - no config file needed, etc :
The above(in red) is why you likely can’t launch a container with ordinary non-root User permissions. Elsewhere in these Forums I’ve posted this anomaly and if I’m interpreting the accompanying RH mail list discussion correctly, this is a suspect setting that might open a vulnerability so won’t likely be changed soon. Bottom line, la unch with root permissions. And, for anything else you post in this thread it should be assumed that you executed commands with root permissions.
Need to verify the machines configured on your machine. Recommend running the following and if no error is obvious, post the result
lxc-ls
and
lxc-info temp1
Also, kind of a double-check, if you install the LXC YAST applet, you should be able to manage your containers within YAST (although IMO this is incomplete, it’s good for what it now does and to eyeball your containers from on high).
Thanks for the information on namespace. I noticed that as well, but ran all lxc-execute commands as root with the same issue.
I don’t believe the information you asked for lxc-ls and lxc-info temp1 really apply though as lxc-exec is used to launch a temporary application container, as opposed to lxc-start?
In other words, lxc-ls and lxc-info won’t show temp1
@DenverD
Yeah, that was when he tested whether he could launch a full virtualized OS instance instead of just an application, and the container he built was based on an ubuntu template. His problem isn’t launching a full OS, he’s launching just a virtualized app.
@LewsTherinTelemo
So, I tried your command as well, trying to launch a virtualized instance of top. Interestingly, I got a different error which IMO likely means that I didn’t experience your error(guessing, but I assume a file error would occur before an error related to a Terminal Environment)
# lxc-execute -n temp1 -- 'top'
TERM environment variable not set.
I’d have to do some research how to address my error, my brief investigation suggests that there is default LXC configuration set.
Mine is still a largely default LXC install configuration except for my efforts to troubleshoot networking(BTW - Did you create a default LXC config?)
Which leads me to your referenced Debian bug… Aside from the last post suggesting that they fixed the problem, it appears to have been an improper path which I highly doubt would be related to what you described.
You might be affected by something I’ve been banging my head against the last 3 days(and apparently corrupted a virtual bridge device in the process), I’ve curiously found that I can ping between containers and containers to Host, but I cannot establish any kind of TCP/IP session from the Host to any container. I found the brdge defice filtering scripts, and the general recommendation to disable (I’ll have to read up more on exactly what these scripts do, and if there is an ebtables configurator or if the same rules more or less are used in iptables and ebtables).
cd /proc/sys/net/bridge for f in bridge-nf-*; do echo 0 > $f; done
But, after eliminating everything relating to known running firewalls and net filters, I’m still experiencing the problem, and might be what you are seeing, too.
Just made a discovery which likely fixes your problem, too.
SUSE FW does not automatically configure virtual bridge devices for the Internal Zone. In my case, this was further exacerbated by the fact I used libvirt to create my virtual bridge devices instead of YAST and SUSE FW didn’t import that information I’ve submitted a bug at https://bugzilla.novell.com/post_bug.cgi
So, first step is whether you know the name of the virtual bridge device you’re using… If you created in YAST you can re-run the Netwrok Settings applet or you can run
brctl show
Then open YAST FW > Interfaces
If your bridge device is listed, make sure it’s configured for the appropriate zone. For me, since a libvirt-created bridge device automatically creates a NAT and CHCP enabled virtual network, I can safely enter into the Internal Zone. You may want to re-think exactly what you need if you’re bridging directly to a public or exposed network, maybe in the external or DMZ with specific ports open.
If your bridge device is not listed (eg if created by libvirt in my case), use the “Custom” button to create a new free form entry, but SUSE FW only supports one entry. For more, currently you’ll have to edit iptables directly.
Stop/Restart the FW.
Don’t forget to disable all bridge filters (more than likely should be done). Correcting my previous post which was missing a line break,
cd /proc/sys/net/bridge
for f in bridge-nf-*; do echo 0 > $f; done
Result:
For me, it looks promising and so I think should work for you, too. Am still verifying it’s a full, persistent fix.
I’m having the same problem with lxc-execute. I’m trying to get a simple containerized testing environment (which is working on ubuntu 12.04LTS) working on my personal system (OpenSUSE 12.3.5, up to date as of today).
The system is a laptop running 3.7.10-1.4-desktop #1 SMP PREEMPT and connected to wifi via the Network Manager. In my case I just want a separate loopback environment working in the container.
I’ve had KVM running with the ubuntu image but switched to the free vmware player to better match the rest of my team at work (hopefully this sheds light on the bridge setup situation).
At first I couldn’t see a bridge device with
brctl show
, after some manual configuring, including turning off the bridge filters as you suggested and with ifcfg-br0 set to:
$ ifconfig
br0 Link encap:Ethernet HWaddr 00:90:F5:D8:38:83
inet addr:192.168.50.1 Bcast:192.168.50.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
but I’m still getting:
$ sudo lxc-execute --name lxctest -s lxc.utsname=foo -s lxc.network.type=empty -s lxc.network.flags=up -- /bin/bash
lxc-execute: No such file or directory - failed to create symlink for kmsg
lxc-execute: failed to setup kmsg for 'lxctest'
lxc-execute: failed to setup the container
lxc-execute: invalid sequence number 1. expected 2
lxc-execute: failed to spawn 'lxctest'
The exact same command above is working fine under my ubuntu 12.04 VM.
Ok.
I spent a couple hours looking at this, and I think I can resolve these errors,
Re: lxc-execute -n foo – top
Can’t do this, because even for application containers they need to use existing template files to describe the container (which is why you’re getting missing file errors). You can see the list of available templates by the following
ls /usr/share/lxc/templates
You can launch top within a Busybox LXC application container as follows
lxc-create -n busybox -t busybox
lxc-execute -n busybox -- top
Re:sshd
I’ll need more time to see if there is a similar path error on an openSUSE file system, interestingly though running lxc-execute instead of lxc-start looks like it might work if a command is passed (I didn’t try that) so the linking error might be non-critical, needs more testing.
@gigadude
See my earlier post, be sure you also verify SUSE FW isn’t blocking your br0
And, my comment above about running top also applies to your “lxctest” container since I don’t see how it’s created, based on what template or file.
Thanks for all the tips. Apparently, lxc-executes default behavior changed. It used to not require a template (or perhaps used a default one if none was specified.) I created a busybox container, and was then able to run
lxc-execute -n busybox -- top
However, whereas the default-behavior used to also allow you to run graphical applications out of the box, such as:
lxc-execute -n temp -- 'chromium'
This now does not work, as you need a ‘real’ template. And of course if you just us the busybox or other provided examples don’t find chromium (as the rootfs is not defined I imagine?)
I decided to build lxc-execute for using the 0.9 source ( git clone git@ssh.github.com:lxc/lxc.git ), but even then I run into:
Hummm - it seems lxc (at least for application containers via lxc-execute) is become something “mere mortals” are not likely to have much success with, which is very much too bad. (Granted, it’s a work in progress.)
I made a little progress on getting lxc up and working for my use case. This is a script (which works fine for me on Ubuntu 12.04LTS with lxc 0.7.5)
basically does:
Where RUN_USER is some user and RUN_COMMAND is the payload to run in the container. All the configuration needed is in the command-line
arguments, it uses the host filesystem directly but isolates network operations, which is exactly what I want in order to run client-server tests.
First, the lxc version on 12.3 is newer (0.8.0), which might just mean the old functionality is no longer supported (I’ve yet to confirm this).
I tried adding /dev and /proc mountpoints to /usr/lib64/lxc/rootfs and did manage to seemingly start an lxc-execute bash session, but this left
my system in a very bad state (the second time I tried to invoke the lxc-execute it failed and I got very worrisome messages which made rebooting
seem the better course). I’ve tried this using the 3.7.10-1.16-default kernel. Has anyone gotten this use case working?