Buggy behaviour always deserves an assertion.
Signed-off-by: Greg Kurz <gkurz@fr.ibm.com>
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
As specified by FHS:
/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts.
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Previous path was $libdir/lxc, changed to $libdir/lxc/rootfs.
Added a README file to be placed in this directory, describing
the purpose of this empty directory. Having a file to be installed
in this directory makes the Makefile to automatically create the
directory at install time.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
capabilities are reseted just after the filesystem is mounted.
lxc_setup_fs() is moved up, before the process is forked.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The following patch wrap the calls on the synchronisation
socketpair in a lxc_sync_ API. It hopefully clarifies what
is done in the start sequence to the expense of more lines
of code ...
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
now that we have specific operations and specific arguments for each
sequence, lxc_restart() and lxc_start() can easily be merged under
a common subroutine.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
the following patch moves the start argument in private
structs which are opaque to lxc_spawn(). To achieve this goal,
we need to move the sv[2] socketpair and lxc_handler
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
These are trivial changes:
start_arg->name is redundant with lxc_handler->name
sv[2] can be stored directly under start_arg
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
struct lxc_operations offers 2 operations : start and post_start
which are used by the lxc-start and lxc-restart sequences to
define specific actions.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
In order to define a specific function for restart, let's create
an ops where we will be able to specify a function for restart too.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
In order to be able to use a single 'start' function for start
and restart, let's prepare do_start to get an extra statefile parameter.
Signed-off-by: Michel Normand <normand@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
I did a little investigation about runlevels and i think we can assume
runlevels 2-5 as normal. So, we can check if system was in runlevel 2-5
and proc count is 1 and now we are in 0/6.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: Denis Rizaev <Denis.Rizaev@trueoffice.ru>
That breaks the reboot because when we reexec, fd 0 and fd 1 will be
closed and these one are created by lxc, not inherited.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Add the broadcast specification, if none is specified, it is automatically
computed from the addr & mask.
syntax:
lxc.network.ipv4 = 172.20.0.2/24 172.20.255.255
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
The removal does not account for possible leading path components that
were also created during creation of pivotdir.
Signed-off-by: Ferenc Wagner <wferi@niif.hu>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
As we defined a path where to mount the rootfs, we can use without
ambiguity because it is defined by default at compile time or by the
configuration.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
We have pivot_dir and rootfs defined in lxc_conf structure.
Let's encapsulate them in a rootfs structure.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Add a configure option to set a mount point path when using a rootfs,
that will replace the actual behavior which creates uneeded /tmp/lxc**
directories.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Ferenc Wagner <wferi@niif.hu> writes:
> Daniel Lezcano <dlezcano@fr.ibm.com> writes:
>
>> Ferenc Wagner wrote:
>>
>>> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>>>
>>>> Ferenc Wagner wrote:
>>>>
>>>>> While playing with lxc-start, I noticed that /tmp is infested by
>>>>> empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs
>>>>> in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the
>>>>> original /tmp is not available anymore, so rmdir(tmpname) at the
>>>>> bottom of setup_rootfs can't achieve much. Why is this temporary
>>>>> name needed anyway? Is pivoting impossible without it?
>>>>
>>>> That was put in place with chroot, before pivot_root, so the distro's
>>>> scripts can remount their '/' without failing.
>>>>
>>>> Now we have pivot_root, I suppose we can change that to something cleaner...
>>>
>>> Like simply nuking it? Shall I send a patch?
>>
>> Sure, if we can kill it, I will be glad to take your patch :)
>
> I can't see any reason why lxc-start couldn't do without that temporary
> recursive bind mount of the original root. If neither do you, I'll
> patch it out and see if it still flies.
For my purposes the patch below works fine. I only run applications,
though, not full systems, so wider testing is definitely needed.
Thanks,
Feri.
>From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001
Date: Thu, 6 May 2010 14:47:39 +0200
That was put in place before lxc-start started using pivot_root, so
the distro scripts can remount / without problems.
Signed-off-by: Ferenc Wagner <wferi@niif.hu>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Bind mount host library path.
Weird but some distro provide busybox as a dynamically linked binary.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
With a friend, we installed lxc on his server.
We spend 1 hour on the kernel config because we didn't knew :
- that lxc-checkconfig is a bash script and it can check a config before
running it
- which kernel config item whas not good
- that CONFIG_SECURITY_FILE_CAPABILITIES is obsolete since 2.6.33
So, here is a patch for lxc-checkconfig that could save time for lxc newbies
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Modified-by: Daniel Lezcano <daniel.lezcano@free.fr>
Signed-off-by: Guillaume Zitta <lxc@zitta.fr>
"lxc configure does not exist. You need to run ./autogen.sh to create it.
I think it needs to either be documented in INSTALL or you provide ./configure"
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Reported-by: Jamal Hadi Salim <hadi@cyberus.ca>
First of all, when trying to start a container in a read-only root
lxc-start complains:
lxc-start: Read-only file system - can't make temporary mountpoint
This is in conf.c:setup_rootfs_pivot_root() function. That function
uses optional parameter "lxc.pivotdir", or creates (and later removes)
a temporary directory for pivot_root. Obviously there's no way to
create a directory in a read-only filesystem.
But lxc.pivotdir does not work either. In the function mentioned above
it is used with leading dot (eg. if I specify "lxc.pivotdir=pivot" in
the config file the pivot_root() syscall will be made to ".pivot" with
leading dot, not to "pivot"), but later on it is used without that dot,
and fails:
lxc-start: No such file or directory - failed to open /pivot/proc/mounts
lxc-start: No such file or directory - failed to read or parse mount list '/pivot/proc/mounts'
lxc-start: failed to pivot_root to '/stage/t'
(that's with "lxc.pivotdir = pivot" in the config file). After symlinking
pivot to .pivot it still fails:
lxc-start: Device or resource busy - could not unmount old rootfs
lxc-start: failed to pivot_root to '/stage/t'
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
When the client console exits, the mainloop goes in an infinite loop
as the handler is not removed and we are notified from the disconnection
indefinitely.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
If the SIGCHLD is sent from a process different from the container's init
process we ignore it, otherwise we finish to wait it.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
When the init container is stopped, we don't check this condition
and we assume the child exited and we wait indefinitely for the child
to exit while this one is stopped.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
