Clear env before starting a container. Do it right before setting
the container=lxc variable.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Add option to create a pidfile for lxc-start. This is helpful for
init scripts and process monitors when running as daemon.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Starting a container with insufficient privilege (correctly) fails
during lxc_init. However, if starting a daemonized container, we
daemonize before we get to that check. Therefore while the
container will fail to start, and the logfile will show this, the
'lxc-start -n x -d' command will return success. For ease of
scripting, do a check for the required privilege before we exit.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.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>
Let's export the 'container' variable and let init receive it
as a kernel command line option.
In the upstart init scripts, we can distinguish if we are in a
container context or not.
===============================================================================
# /dev/console - getty
#
# This service maintains a getty on /dev/console from the point the
# system is started until it is shut down again.
# It only runs in lxc containers.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
env container
pre-start script
[ "x$container" != "xlxc" ] && { stop; exit 0; }
exit 0;
end script
respawn
exec /sbin/getty -8 38400 /dev/console
===============================================================================
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When the reboot is detected, reboot the container.
That needs to set all file descriptor opened by lxc-start
to be flagged with the close-on-exec flag, otherwise when
re-execing ourself, we inherit our own fd.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The actual behaviour of the console is messy as:
* it relies on a heuristic (tty or not, rootfs or not, etc ...)
* the container init stole the tty and we lose the control
The following patch:
* allocates a tty
* maps this tty to the container console
* proxy the io from the console to the file specified in the configuration
lxc.console=<file>
That allows to specify a file, a fifo, a $(tty), and can be extended with an
uri like file://mypath, net://1.2.3.4:1234, etc ...
That solves the problem with the heuristic and the container does no longer stole
our current tty.
Note by default, the console output will go to a blackhole if no configuration is
specified making the container showing nothing.
In order to access the console from the tty, use
lxc-start -n foo -s lxc.console=$(tty)
I propose the make the container to daemonize by default now.
I tried the following:
in a shell:
touch /var/lib/lxc/foo/console
tail --retry -f /var/lib/lxc/foo/console
in another shell:
lxc-start -n foo -s lxc.console=/var/lib/lxc/foo/console
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
lxc_<cmd>.c and <cmd>.c files use the same log category : lxc_<cmd>.
The symbol is multiply defined and linking statically lxc commands is
not possible.
The patch introduces new log categories with a '_ui' suffix to
differentiate the command line interface from the library routine.
Reported-by: Ciprian Dorin, Craciun <ciprian.craciun@gmail.com>
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
conf object is on stack and is used in forked process.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If you're running (by mistake or typo) (via lxc-start) container that does not
exists it will run with lxc.rootfs=/, meaning that /sbin/init will
restart initialization procedure, efficiently messing host's system,
that may lead to unpredictable results or even destroy (make inaccessible) host
system (by reseting network configuration or something like that).
(Actually, it _did_ destroy system of everyone who tested this).
Actually, I finally lost any meaning of having such a feature for
full-system containers. You may not use hosts's FS - it's described at
above. You may not use some temporary directory - that's nonsense.
This patch forbinds starting container via lxc-start without rcfile and
custom start program, but probably it fixes only small part of problem.
I really don't see much sense in such a feature without ability of
overriding 'default' setting with command line switches. Anyway, default
behaviour should be as save as possible.
Signed-off-by: Andrian Nord <NightNord@gmail.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The rcfile is parsed in the lxc_start function. This is not the place
to do that. Let's the caller to do that.
In the meantime, we have the lxc_conf structure filled right before
calling the lxc_start function so we can do some sanity check on the
configuration to not break the system when we launch the container.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The container will be a directory where the user can store everything,
so we create one directory and store a configuration file inside.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
With the previous modifications, a temporary directory is created
to mount the rootfs in order to have the system container to remount
itself the '/' directory.
But in case of daemonize, we change the directory, so when the rootfs
is specified with a relative path, we can not access it.
Don't chdir, as that will be done automatically later in the chroot
setup.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The command specifies a configuration file => use it
The command does not specify a configuration but the container
was created before, use the configuration.
The command does not specify a configuration and the container
was not created before, use default.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
<lxc/lxc.h> should only include what is needed. This patch removes
all useless headers from lxc.h and fixed other .c files.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When a container was created, its configuration is used.
When a container was not created, the configuration specified in
the command line is used, if not configuration file is used,
default values are used.
That allows to create 'volatile' container, like tmp files.
It is useful for example to spawn different container with the
same generic configuration file. That let the user to have its own
repository of configuration files.
And, more important, that fix temporary created container with
lxc-execute to be not deleted when the host crash or the command
is killed.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This patch fix a problem with the commit d983b93c3a
When the lxc daemonize, it closes fd 0, 1 and 2. But these ones are coming from
inherited fd and they are already in the inherited list of fd. When lxc creates
some file descriptors, they have the number of the previous inherited file
descriptor, so they are closed when we close all the inherited file descriptors.
In order to fix that, the lxc_close_inherited_fd function has been implemented
to close an inherited fd and remove it from the list.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When we daemonize the container and we specify the log file,
the container will use the log file to write the console output.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If needed the container can be launched in background
with a specific option -d.
That will make mute the container, the logs can help
to check what went wrong.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Save the tty configuration before calling lxc_start and
restore it right after it has been changed.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The exit code of the application as reported by lxc-start is:
0-126 exit code of the application itself
128+n signal n received by the application
255 lxc error
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
add the long options to lxc-start
with a small change in lxc_start proto to avoid compilation warning
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This added quiet option allow to disable
the reporting via stderr of the lxc error messages.
Note that the usage function is still printing in case of error,
but will be removed by later patches
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
report error in lxc_get_lock and remove the call to lxc_strerror
that become useless for these errors.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
this is adding -o and -l options to all cli of lxc
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
do it in all cli, except:
* the usage functions that will be removed by another patch
* the lxc_init that need more work
* the lxc_priority that is not used anymore
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
This patch defines a new log category in each file using logging and
replaced the former logging routines with the new ones.
Signed-off-by: Cedric Le Goater <legoater@free.fr>
Acked-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
From: Daniel Lezcano <daniel.lezcano@free.fr>
Fixed the type of the opt variable. On the powerpc architecture, that leads
to an infinite loop in the getopt inspection because getopt returns 255
instead of -1 as expected. The opt variable should be an int and not a char.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
When no command is specified is specified for lxc-start, the "/sbin/init"
is automatically used.
Signed-off-by: Daniel Lezcano <dlezcano@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>
