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>
