If we don't re-open these after clone, the init process has a pointer to the
parent's /dev/{zero,null}. CRIU seese these and wants to dump the parent's
mount namespace, which is unnecessary. Instead, we should just re-open
stdin/out/err after we do the clone and pivot root, to ensure that we have
pointers to the devcies in init's rootfs instead of the host's.
v2: Only close fds if the container was daemonized. This didn't turn out as
nicely as described on the list because lxc_start() doesn't actually have
the struct lxc_container, so it cant see the flag. Instead, we just pass it
down everywhere.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
We want to close all inherited fds in three cases - one, if a container
is daemonized. Two, if the user specifies -C on the lxc-start command
line. Three, in src/lxc/monitor.c. The presence of -C is passed in the
lxc_conf may not always exist.
One call to lxc_check_inherited was being done from lxc_start(), which
doesn't know whether we are daemonized. Move that call to its caller,
lxcapi_start(), which does know.
Pass an explicit closeall boolean as second argument to lxc_check_inherited.
If it is true, then all fds are closed. If it is false, then we check
the lxc_conf->close_all_fds.
With this, all tests pass, and the logic appears correct.
Note that when -C is not true, then we only warn about inherited fds,
but we do not abort the container start. This appears to have ben the case
since commit 92c7f62955 in 2011. Unfortunately the referenced URL with
the justification is no longer valid. We may want to consider becoming
stricter about this again. (Note that the commit did say "for now")
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Move choose_init into utils.c so we can re-use it. Make it and on_path
accept an optional rootfs argument to prepend to the paths when checking
whether the file exists.
Also add lxc.init.static to .gitignore
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Using the multiarch dir causes problems when running lxc-execute
on amd64 with an i386 container. /sbin/lxc-init is a more confusing
name and will show up in 'lxc<tab>'. /sbin/init.lxc should be quite
obvious as an init for lxc.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Currently due to some safety checks for !rootfs.path, lxc-execute works
ok if you do not set lxc.rootfs at all in your lxc.conf. But if you
set lxc.rootfs = '/', then it sets up console, and when you do an
lxc-execute, the console appears hung.
However the lxc.rootfs NULL check was just incidental to not dereference
a NULL pointer. In fact we should not be setting up a console if the
container isn't running a full-fledged distro with a getty/login
running on the container's /dev/console.
Have lxc_execute() mark in lxc_conf that this is a lxc-execute and not
an lxc-start, and don't set up the console.
The issue is documented at https://sourceforge.net/p/lxc/bugs/67/ .
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Dwight Engen <dwight.engen@oracle.com>
Right now if we use lxc-execute without log level set, we get error:
lxc: invalid log priority NOTSET.
Because we set log level manually in execute_start(), but didn't
check if we have a valid log level or not, so fix it.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Since lxc_execute() is available through the library and is exposed via
the API we cannot be sure the caller will immediately exit, so we should
take care to free the allocated memory.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
On Mon, 29 Apr 2013 14:44:47 -0500
Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> Quoting Dwight Engen (dwight.engen@oracle.com):
> > So I did this, only to realize that lxc-init is passing "none" for
> > the file anyway, so it currently doesn't intend to log. This makes
> > me think that passing NULL for lxcpath is the right thing to do in
> > this patch. If you want me to make it so lxc-init can log, I can do
> > that but I think it should be in a different change :)
>
> That actually would be very useful, but as you say that's a different
> feature - thanks.
... and here is said change.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
The previous lxcpath patches added support for a custom LXCPATH set
through a system-wide configuration file.
This was also exposed through the C api, so that a custom lxcpath could
be set at the container object instanciation time, or set at runtime.
However the command sock filename was always located under the global
lxcpath, which could be confusing, and would be a problem for users
with insufficient perms to the system-wide lxc path (i.e. if setting
lxcpath to $HOME/lxcbase). This patch changes that by passing the
lxcpath to all callers of lxc_command().
It remains to add an lxcpath command line argument to most of the
command line tools (which are not using the C api) - lxc-start,
lxc-info, lxc-stop, etc.
At this point it becomes tempting to do something like
c = lxc.Container("r1", "/var/lib/lxc")
c2 = lxc.Container("r1", "$HOME/lxcbase")
However, that's problematic - those two will use the same directory
names for cgroup directories.
What would be the best way to handle this? One way (which I kind
of like) is to give up on naming the cgroups after the container.
use mkstemp for the cgroup name, let lxc keep track of the cgroup
name based on the command socket, and make users use lxc-cgroup to get
and change settings.
Other ideas?
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
When a physical nic is being set up, store its ifindex and original name
in struct lxc_conf. At reboot, reset the original name.
We can't just go over the original network list in lxc_conf at shutdown
because that may be tweaked in the meantime through the C api. The
saved_nics list is only setup during lxc_spawn(), and restored and
freed after lxc_start.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1086244
Changelog: remove non-effect change in execute.c
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
lxc-init used to be under /usr/lib/lxc. Now it is under
/usr/lib/<multiarch>/lxc, but old containers will still have it under
/usr/lib/lxc. So search for a valid lxc-init to run.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The option is implied by '-d', because the admin won't see the warning
message.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This patch allows to create application containers with liblxc.so directly.
Some code cleanups on the way:
- separate ops for lxc_execute() and lxc_start(): the factorisation is wrong
here as we may have specific things to do if we're running an application
container. It deserves separate ops.
- lxc_arguments_dup() is merged in the pre-exec operation: this is a first
use for the execute op introduced just above. It's better to build the
arguments to execvp() where they're really used.
Signed-off-by: Greg Kurz <gkurz@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
The main difference between lxc_start and lxc_execute is the latter creates
an intermediate process to wait for all the childs. That allows to support
daemons or orphan process group for the pid namespace.
Having such difference makes the code to be duplicate between the two
functions. So instead of doing this, I create an intermediate <init> program
which is in charge to launch the specified command. This command is the
lxc-init program taking different options:
--mount-procfs : mount the proc filesystem before exec'ing the command
--mount-sysfs : mount the sys filesystem before exec'ing the command
A double dash indicates the end of the options of lxc-init and the beginning
of the command to be launched.
To summarize:
* lxc_execute function is no more.
* lxc-execute command uses the lxc_start function and launch the specified
command via lxc-init
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
