This new option is to have user to pass a fd
in place of statefile name.

Simple usage with file open in bash:
===
$rm -f *.log; lxc-execute -n foo -- pi1  44444
$rm -rf /tmp/sf; lxc-checkpoint -n foo -k --statefd 3 3>/tmp/sf && lxc-restart -n bar --statefd 4 4</tmp/sf
===
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

the fd 0,1 and 2 are still inherited
and we only need the fd 2 (stderr) after
the start/restart of the application.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fail when we try to attach to an non existing container
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

This patch will try to change the default "/" directory to the
directory we were before attaching. In order to work correctly,
the path has to exist in the container, that makes sense with a
shared file system without rootfs.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The command to attach has to be fork/exec.
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>

This patch allows to shutdown the container when the system
is powered off in the container.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Store the container in the handler, so it is accessible
everywhere.
Signed-off-by: Daniel Lezcano <dlezcan@fr.ibm.com>

This patch adds a function to count the number of tasks in the
container. The result is not reliable as it may change with a fork
or an exit, but in some cases, for example, there is only one task, or
the container is frozen, the result is accurate.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When no console is specified, do not try to setup the console.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

based on patch from: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>

but also:
* remove the deprecated --directory one.
* change liblxc api of checkpoint/restart to use fd and not string.
* explicitely report error messages for the checkpoint/restart stub functions.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fix type and missing capability.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The log file in lxc-init is quite useless as the code is trivial.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Wrong variable.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When we try to attach to a container belonging to another user than us,
the command fails as expected but the return code is wrong, so we have
an "unknown error" instead of "permission denied".

The culprit is:

-                     strerror(command.answer.ret));
+                     strerror(-command.answer.ret));

The rest of the code is indentation without code impact.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: Michel Normand <normand@fr.ibm.com>

This patch allows to execute a command or enter inside the container:
  * lxc-attach -n <name> [command]

If the <command is not specified>, the lxc-attach will retrieve your uid
and get your shell name and exec it in the container.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Open the console at the setup time, otherwise the openeded
file descriptor will be considered as an inherited fd and the
startup will fail.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

This patch modifies the startup of a container to forbid opened
fds, unless these are stdios.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>

In the process of rollbacking, the handler->pid is not set
we must not kill it. Otherwsise, kill(-1, SIGKILL), ouch ! ...
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Add the console.h file in order to compile the dist file.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Delete the network devices when an error occurs before they are moved
to the network namespace (network namespace destruction triggers the
network devices deletion). Otherwise they stay in the system.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fix inconsistent function definition regarding the headers.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Add a function to delete the network device by its index.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fix the warning:

start.c: In function ‘lxc_fini’:
start.c:250: warning: implicit declaration of function ‘lxc_unlink_nsgroup’
start.c: In function ‘lxc_spawn’:
start.c:380: warning: implicit declaration of function ‘lxc_rename_nsgroup’
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The patch fixes a build error on the devel version of Fedora.
Signed-off-by: Silas Sewell <silas@sewell.ch>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When the umount fails, we force the umount and make the mount point
unaccessible by using a lazy umount.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When there is no rootfs, don't create a console.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

As the console output can be a tty, we want to have the terminal to
be set as a specific manner to not echo and receive signals from the
keyboard.
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>

Use a prefixed enum to avoid conflict later.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

No need to include the lxc_conf structure definition, a forward
declaration is enough.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Use the mainloop to manage io of the console.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Factor out the console code and encapsulate the code in
functions.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When there is an empty network namespace, we must not move the
network device.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Add missing include
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Do not check CPUSET configuration when SMP is not enabled.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Increment to 0.6.5 version.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

There are several cases where the system can no longer access a mount
point or a mount point configuration makes the algorithm bogus.

For example, we mount something and then we chroot, the mount information
will give an unaccessible path and the container won't be able to start
because this mount point will be unaccessible. But if it's the case, then
we can just warn and continue running the container.

Another case is the path to a mount point is not accessible because there
is another mount point on top of it hiding the mount point. So the umount
will fail and the container won't start.

Easy to reproduce:

mkdir -p /tmp/dir1/dir2
mount -t tmpfs tmpfs /tmp/dir1/dir2
mount -t tmpfs tmpfs /tmp/dir1

So can we just ignore the error when unmounting and continue to the list again
and again until it shrinks.

At the end, we just display the list of the unmounted points.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>