In the past, lxc-cmd-stop would wait until the command pipe was closed
before returning, ensuring that the container monitor had exited.
Now that we accept the actual success return value, lxcapi_stop can
return success before the monitor has fully exited.
So explicitly wait for the container to stop, when lxc-cmd-stop returned
success.
1. When we stop a container from the lxc_cmd stop handler, we kill its
init task, then we unfreeze the container to make sure it receives the
signal. When that unfreeze succeeds, we were immediately returning 0,
without sending a response to the invoker.
2. lxc_cmd returns the length of the field received. In the case of
an lxc_cmd_stop this is 16. But a comment claims we expect no response,
only a 0. In fact the handler does send a response, which may or may
not include an error. So don't call an error just because we got back a
response.
Since attach asks the restore process what the clone flags were, if we forgot
to set them then the attach command ran in the hosts namespaces instead of the
containers, which is a Very Bad Thing :). Instead, we remember to set the clone
flags in the restore process' handler, so that we report them correctly to any
attach processes who ask.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Tycho Andersen [Fri, 20 Mar 2015 16:17:31 +0000 (10:17 -0600)]
lxcapi_restore shouldn't steal the calling process
Previously, lxcapi_restore used the calling process as the lxc monitor process
(and just never returned), requiring users to fork before calling it. This, of
course, would cause problems for things like LXD, which can't fork.
Now, restore() forks the monitor as a child of the process that calls it. Users
who want to daemonize the restore process need to fork themselves.
lxc-checkpoint has been updated to reflect this behavior change.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Fix incomplete destruction of unprivileged ephemeral containers
If an unprivileged ephemeral container is started as follows,
lxc-start-ephemeral -o trusty -n test_ephemeral
Then an empty directory remains upon exit from the container,
~/.local/share/lxc/test_ephemeral/tmpfs/delta0
(The tmpfs filesystem is successfully unmounted, but we seem to lack
permission to delete the delta0 directory).
This issue arose following commits 4799a1e and dd2271e .
The following patch resolves the issue. It has been tested on ubuntu
14.04 with the lxc-daily ppa.
Since gmail screws up the formatting of the patch via line-wrapping
etc, please copy the patch from the issue-tracker rather than from
this email.
Serge Hallyn [Mon, 16 Mar 2015 17:02:12 +0000 (17:02 +0000)]
lxc-destroy: actually work if underlying fs is overlayfs
One of the 'features' of overlayfs is that depending on whether a file
is on the upper or lower dir you get back a different device from stat.
That breaks our lxc_rmdir_onedev.
So at lxc_rmdir_ondev check the device of the directory being deleted.
If it is overlayfs, then skip the device check.
Note this is unrelated to overlayfs snapshots - in those cases when you
delete a container, /var/lib/lxc/$container/ does not actually have an
overlayfs under it. Rather, to reproduce this you would
Serge Hallyn [Wed, 18 Mar 2015 00:02:18 +0000 (19:02 -0500)]
cgmanager: put unprivileged containers under $(curcgroup)/lxc/$(container0
Currently if we are in /user.slice/user-1000.slice/session-c2.scope,
and we start an unprivileged container t1, it will be in cgroup
3:memory:/user.slice/user-1000.slice/session-c2.scope/t1. If
we then do a 'lxc-cgroup -n t1 freezer.tasks', cgm_get will
first switch to 3:memory:/user.slice/user-1000.slice/session-c2.scope
then look up 't1's values. The reasons for this are
1. cgmanager get_value is relative to your own cgroup, so we need
to be sure to be in t1's cgroup or an ancestor
2. we don't want to be in the container's cgroup bc it might freeze us.
But in Ubuntu 15.04 it was decided that
3:memory:/user.slice/user-1000.slice/session-c2.scope/tasks should
not be writeable by the user, making this fail.
Therefore put all unprivileged cgroups under "lxc/%n". That way
the "lxc" cgroup should always be owned by the user so that he can
enter.
Serge Hallyn [Wed, 11 Mar 2015 22:10:55 +0000 (22:10 +0000)]
logs: introduce a thread-local 'current' lxc_config
The logging code uses a global log_fd and log_level to direct
logging (ERROR(), etc). While the container configuration file allows
for lxc.loglevel and lxc.logfile, those are only used at configuration
file read time to set the global variables. This works ok in the
lxc front-end programs, but becomes a problem with threaded API users.
The simplest solution would be to not allow per-container configuration
files, but it'd be nice to avoid that.
Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible",
but would be a huge complication as there are many functions, including
struct member functions and callbacks, which don't have that info and
would need to get it from somewhere.
So the approach I'm taking here is to say that all real container work
is done inside api calls, and therefore the API calls themselves can
set a thread-local variable indicating which log info to use. If
unset, then use the global values. The lxc-* programs, when called
with a '-o logfile' argument, set a global variable to indicate that
the user-specified value should be used.
In this patch:
If the lxc container configuration specifies a loglevel/logfile, only
set the lxc_config's logfd and loglevel according to those, not the
global values.
Each API call is wrapped to set/unset the current_config. (The few
exceptions are calls which do not result in any log actions)
Update logfile appender to use the logfile specified in lxc_conf if (a)
current_config is set and (b) the lxc-* command did not override it.
This patch enables seccomp support for LXC containers running on PowerPC
architectures. It is based on the latest PowerPC support added to libseccomp, on
the working-ppc64 branch [1].
Libseccomp has been tested on ppc, ppc64 and ppc64le architectures. LXC with
seccomp support has been tested on ppc and ppc64 architectures, using the
default seccomp policy example files delivered with the LXC package.
brauner [Sun, 8 Feb 2015 15:48:31 +0000 (16:48 +0100)]
config: Allow all containers to use fuse
This enables containers to mount fuse filesystems per default. The mount
is designed to be safe. Hence, it can be enabled per default in
common.conf. It will lead to a cleaner boot for some unprivileged
systemd-based containers.
Signed-off-by: Christian Brauner <christianvanbrauner@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Stéphane Graber [Mon, 2 Feb 2015 09:21:20 +0000 (11:21 +0200)]
In lxc.mount.auto, skip on ENONENT
This resolves the case where /proc/sysrq-trigger doesn't exist by simply
ignoring any mount failure on ENOENT. With the current mount list, this
will always result in a safe environment (typically the read-only
underlay).
Closes #425
v2: Don't always show an error
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Tycho Andersen [Wed, 4 Feb 2015 12:02:02 +0000 (14:02 +0200)]
Process command line is null terminated
It turns out the process command line is in fact null terminated on the stack;
this caused a bug where when the new process title was smaller than the old
one, the first environment entry would be rendered as part of the process
title.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Tycho Andersen [Fri, 30 Jan 2015 13:59:13 +0000 (14:59 +0100)]
set the monitor process title to something useful
Instead of having a parent process that's called whatever the caller of the
library is called, we instead set it to "[lxc monitor] <lxcpath> <container>"
Closes #180
v2: check for null in tok for loop, only truncate environment when necessary
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Serge Hallyn [Thu, 29 Jan 2015 23:50:41 +0000 (23:50 +0000)]
apparmor: support lxc.ttydir when bind-mounting ptys
Because we now create the ttys from inside the container, we had to
add an apparmor rule for start-container to bind-mount /dev/pts/** -> /dev/tty*/.
However that's not sufficient if the container sets lxc.ttydir, in
which case we need to support mounting onto files in subdirs of /dev.
Serge Hallyn [Thu, 29 Jan 2015 16:09:45 +0000 (16:09 +0000)]
clone_paths: use 'rootfs' for destination directory
We were trying to be smart and use whatever the last part of
the container's rootfs path was. However for block devices
that doesn't make much sense. I.e. if lxc.rootfs = /dev/md-1,
chances are that /var/lib/lxc/c1/md-1 does not exist.
So always use the $lxcpath/$lxcname/rootfs, and if it does
not exist, try to create it.
With this, 'lxc-clone -s -o c1 -n c2' where c1 has an lvm backend
is fixed. See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1414771
Serge Hallyn [Thu, 29 Jan 2015 10:13:36 +0000 (10:13 +0000)]
create lxc.tty ptys from container process
Lxc has always created the ptys for use by console and ttys early
on from the monitor process. This has some advantages, but also
has disadvantages, namely (1) container ptys counting against the
max ptys for the host, and (2) not having a /dev/pts/N in the
container to pass to getty. (2) was not a problem for us historically
because we bind-mounted the host's /dev/pts/N onto a /dev/ttyN in
the container. However, systemd hardocdes a check for container_ttys
that the path have 'pts/' in it. If it were only for (2) I'd have
opted for a systemd patch to check the device major number, but (1)
made it worth moving the openpty to the container namespace.
So this patch moves the tty creation into the task which becomes
the container init. It then passes the fds for the opened ptys
back to the monitor over a unix socketpair (for use by lxc-console).
The /dev/console is still created in the monitor process, so that
it can for instance be used by lxc.logfd.
So now if you have a foreground container with lxc.tty = 4, you
should end up with one host /dev/pts entry per container rather than 5.
And lxc-console now works with systemd containers.
Note that if the container init mounts its own devpts over the
one mounted by lxc, the tty /dev/pts/n will be hidden. This is ok
since it's only systemd that needs it, and systemd won't do that.
Serge Hallyn [Tue, 27 Jan 2015 23:06:22 +0000 (23:06 +0000)]
systemd: specify container_ttys in environment
The lxc.tty configuration item specifies a number of ttys to create.
Historically, for each of those, we create a /dev/pts/N entry and
symlink it to /dev/ttyN for older inits to use. For systemd, we should
instead specify each tty name in a $container_ttys environment variable
passed to init.
See http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ and
https://github.com/lxc/lxc/issues/419.
Serge Hallyn [Tue, 27 Jan 2015 09:29:17 +0000 (10:29 +0100)]
fix busybox unpriv
1. tty5 is not needed
2. the devices should be optional in case they didn't exist in the
host / parent-container
3. switch from 'touch $rootfs/dev/$dev' to using create=file in the
mount entry.
Tomas Pospisek [Sun, 25 Jan 2015 15:27:10 +0000 (16:27 +0100)]
improve "lxc-create -t debian -h" help text
- document environment variables
- add missing --packages switch to command line
- describe how to pass template options to lxc-create (since
lxc-create -h doesn't tell you)
- render help text in the same pretty format as lxc-create does
Signed-off-by: Tomáš Posíšek <tpo_deb@sourcepole.ch> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Patrick O'Leary [Wed, 17 Dec 2014 01:47:21 +0000 (19:47 -0600)]
replace deprecated `index` with `strchr`
The `index` libc function was removed in POSIX 2008, and `strchr` is a direct
replacement. The bionic (Android) libc has removed `index` when you are
compiling for a 64-bit architecture, such as AArch64.
Signed-off-by: Patrick O'Leary <patrick.oleary@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Markus Elfring [Sat, 24 Jan 2015 19:38:49 +0000 (20:38 +0100)]
Bug #158: Deletion of unnecessary checks before a few calls of LXC functions
The following functions return immediately if a null pointer was passed.
* container_destroy
* lxc_cgroup_process_info_free_and_remove
* lxc_cgroup_put_meta
* toss_list
It is therefore not needed that a function caller repeats a corresponding check.
This issue was fixed by using the software Coccinelle 1.0.0-rc23.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Markus Elfring [Sat, 24 Jan 2015 18:55:36 +0000 (19:55 +0100)]
Bug #158: Deletion of unnecessary checks before calls of the function "free"
The function "free" is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
This issue was fixed by using the software Coccinelle 1.0.0-rc23.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Kohei YOSHIDA [Thu, 22 Jan 2015 06:16:39 +0000 (15:16 +0900)]
fix failed to fallback at lxclock_name
lxclock_name will fallback to /tmp/$(id -u)/lxc$lxcpath/.$lxcname when failed
to create directories into rundir. But, in currently, lxclock_name returns
untill preparing directories under the /tmp, so invoker will fail to get
the container lock. This patch fixes fixes this.
Signed-off-by: Kohei YOSHIDA <kohei.yoshida@gehirn.co.jp>
Michael Adam [Mon, 19 Jan 2015 21:50:58 +0000 (22:50 +0100)]
add "--mask-tmp" to lxc-fedora, plus some template script fixes]
Hi Michael,
do you have any concerns with the attached patch to
the fedora template that adds an option --mask-tmp
that prevents fedora/systemd from over-mounting
/tmp with tmpfs, which is useful in some cases?
Thanks - Michael
----- Forwarded message from Michael Adam <obnox@samba.org> -----
Date: Sat, 10 Jan 2015 13:12:06 +0100
From: Michael Adam <obnox@samba.org>
To: LXC development mailing-list <lxc-devel@lists.linuxcontainers.org>
Subject: Re: [lxc-devel] [PATCHES] add "--mask-tmp" to lxc-fedora, plus some
template script fixes
User-Agent: Mutt/1.5.23 (2014-03-12)
On 2015-01-10 at 13:08 +0100, Michael Adam wrote:
> On 2015-01-10 at 04:05 +0000, Serge Hallyn wrote:
>
> > The less controversial one is adding mask-tmp to the fedora template.
> > It looks fine to me, but that should go separately to mwarfield, our
> > fedora template maintainer :)
>
> I had notified mhw of my patches on irc, but apparently he is
> currently very busy.
>
> For a start, following is an update of the uncontroversial fix
> patches, i.e. the fix patche without the path ones, and without
> the mask-tmp patch.
And here comes the mask-tmp patch.
It needs to be applied onto the previous fix-patchset.
From 9589dca113535ed2f4faad89db2fab33bb8a9d7e Mon Sep 17 00:00:00 2001
From: Michael Adam <obnox@samba.org>
Date: Thu, 8 Jan 2015 10:25:24 +0100
Subject: [PATCH] lxc-fedora: add a new option --mask-tmp
This will configure the container to prevent the standard
behaviour of over-mounting /tmp with tmpfs, which can be
undesirable in some cases.
My personal use case is vagrant-lxc in combination with
vagrant-cachier.
Signed-off-by: Michael Adam <obnox@samba.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
projects / thirdparty / lxc.git / log
