We don't have to check for the cgroup namespace name because the
pid we are looking for is already in the list of the container owned by
lxc and retrieved from the abstract socket command name.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Take into account we may have the clone_children flag on the cgroup,
so we ignore cgroup namespace in this case.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If ns cgroup is mounted, then when lxc-unshare runs, the kernel automatically
creates a new cgroup for the task. So lxc-unshare tries to delete it. But
if ns cgroup is not mounted, that cgroup does not get created, and now
lxc-unshare spits an error.
Author: Serge Hallyn <serge.hallyn@canonical.com>
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/819319
Forwarded: no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
like lxc-ps and lxc-ls, lxc-netstat breaks if there is not an 'lxc' cgroup
mount and /etc/mtab is not a link to /proc/mounts.
Author: Serge Hallyn <serge.hallyn@canonical.com>
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/819319
Forwarded: no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The cgroup mounts created by cgroup-bin do not show up in /etc/mtab.
lxc-ls, as lxc-ps before it, assumes that /etc/mtab is symlinked to
/proc/mounts.
Author: Serge Hallyn <serge.hallyn@canonical.com>
Forwarded: no
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/819319
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If the keyword 'none' is specified for the console name, lxc will ignore creating a console.
That allows to have a rootfs but without a console.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If /var/run is a symlink to /run in the container, then opening
/proc/<pid>/root/var/run/utmp will end up opening the host's utmp.
Therefore the hack detecting shutdown through utmp fails.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Otherwise apt fails during and after debootstrap.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When '-b user' is specified to lxc-ubuntu container creation template, do
not automatically add all the groups of which user is a member on the host,
to user's groups in the container.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
src/lxc/conf.c will explicitly mount it anyway. Furthermore, the fstab
entry, which is getting processed first, did not specify -o newinstance.
This can cause the host's devpts entry mount options to change, as in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/607636.
Note - I messed up. This was applied upstream, but I dropped it in
subsequent conversion to lxc-ubuntu template. It therefore needs to
be reapplied.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Otherwise building on armel fails with
checking for linux SRCARCH... configure: error: architecture arm-unknown-linux-gnueabi not supported
See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/745884 for details.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Dear all,
while working with systemd I found that lxc-ps -efa does not recognize the
container name.
Best regards Joerg
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
(sorry for the extra traffic.)
With this patch, lxc works for me both with all cgroups mounted with
ns cgroup on /cgroup, and with libcgroup mounting all cgroups
separately.
To do this, instead of looking for one cgroup called 'lxc' or
otherwise taking the first cgroup we find, we actually create a
container in every mounted cgroup fs. Right now it's done under the
root of each fs. We may want to put that under lxc, or, better yet,
make that configurable.
Changelog:
Michael H. Warfield: Handle the case where subsystem doesn't have '.'.
Daniel Lezcano: clean up incorrect reentrant use of mntent helpers
v3: use the rest of Daniel's cleanups
TODO: add a configurable directory name, 'lxc' by default, under which
all lxc cgroups are created (i.e. /sys/fs/cgroup/lxc)
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Tested-by: Michael H. Warfield <mhw@WittsEnd.com>
The good news is, starting with next openSUSE release (and next SLES 11
Service Pack), patching /etc/init.d/boot won't be needed anymore for
LXC, we integrated detection of LXC (through container variable set to
lxc) in /etc/init.d/boot and /dev is no longer mounted automatically by
initscript.
Signed-off-by: Frederic Crozat <fcrozat@suse.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This does not supplant the need for a manpage, but it's a start.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If can't match any valid release, use lucid.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Consolidate lucid, maverick, natty, and oneiric templates into one 'ubuntu'
template.
Add support for specifying architecture.
Add support for '--trim|-x' option, which removes services like the lucid
template used to. This creates smaller, faster-booting containers, but they
will not be safe with certain upgrades, like mountall or udev. When -x is
not specified for lucid or maverick container, then install lxcguest from
the ubuntu-virt ppa, since it does not exist in the official archives, and
the container is not safe to boot without lxcguest.
Add support for '--bindhome <user>' option, which will cause /home/<user>
to be bind-mounted into the container, and create the user with his
original password, shell, and group memberships in the container.
changelog:
june 23:
lxc-ubuntu template: set lxc.arch in config
install lxcguest when NOT trimming the container
lxc-ubuntu: always install lxcguest in postprocess
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This way I can do
lxc-create -t ubuntu -f /etc/lxc.conf -n u1 -- -x
and have -x passed to the template
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Create an lxc-clone script to clone containers. It should probably
be factored into helpers and then enhanced, in particular to convert
between LVM and non-LVM containers, create non-snapshot LVM clones,
support loopback devices, and, when stable enough, to use
overlayfs, btrfs, etc.
But this is a start.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If this is acceptable as is, then I'll try to get a simple lxc-clone
out tomorrow (taking into account your comments from last time).
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When we accept a connection, we have to set the close-on-exec flag,
otherwise that won't be possible to reboot a container through a
lxc-console command.
Reported-by: Katoh Yasufumi <karma@jazz.email.ne.jp>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
It's OK, if /dev/ptmx points to /dev/pts/ptmx via a symlink.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Also add #ifndef for compability with glibc before 2.12.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
'setns.h' is not an lxc interface.
Also, a side effect of this declaration of 'setns.h' in the lxc header
files is to be distributed in the lxc tarball. This breaks the
lxc-attach command because the file is not automatically generated at
compile time.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
We ignore the line of in the configuration file not beginning by "lxc."
So we can mix the configuration file with another information used for
another component through the lxc library.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
src/lxc/conf.c will explicitly mount it anyway. Furthermore, the fstab
entry, which is getting processed first, did not specify -o newinstance.
This can cause the host's devpts entry mount options to change, as in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/607636.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
src/lxc/conf.c will explicitly mount it anyway. Furthermore, the fstab
entry, which is getting processed first, did not specify -o newinstance.
This can cause the host's devpts entry mount options to change, as in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/607636.
I believe the lenny, fedora, and debian templates also will need an
update.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The lxc/ prefix is missing in <start.h>. This breaks the inclusion
of the header file <lxc/conf.h> in external source code.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The default appender for logs is currently the file one: this
make macros from log.h unusable as long as lxc_log_init() hasn't
been called. This prevents errors from even being printed on
stderr in lxc_caps_init() for example.
Let's make stderr the default appender.
Signed-off-by: Greg Kurz <gkurz@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
lxc_cgroup_path_get currently cache the cgroup mount point plus the
container name at the same time, making every call of the function
returning the same value.
It mean that actually every call to lxc_cgroup_get with a different
container name will in fact use the same container name as used for
the primary call.
I join a patch to fix that, still doing some caching, but only caching
the cgroup moint point this time. This patch actually work for me, as
I am using the liblxc for retrieving statistics about all running
containers, using lxc_cgroup_get to retrieve every interesting values.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
