[lxc-devel] [GIT] lxc branch, master, updated. b75afd90891e443f1f9232dc46680ba7a21f189a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via b75afd90891e443f1f9232dc46680ba7a21f189a (commit) via b24319395b9047876e9de03abeb9986441401742 (commit) via b79fcd8638b571043610e80bd465adfa9f08842b (commit) via 8b7329af3fa876aacd6b0299f4d86e76cd3b14a5 (commit) via c3e13372aaa81587772f6ce9074de6013884a484 (commit) via 9d7f9e522b87c250178c53ce671f28e3afd73c1e (commit) via 79e68309225ef94f3be064276f5f9e285bbcfb0f (commit) from 84a24de2355afef00d5779d086b316773fd26460 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit b75afd90891e443f1f9232dc46680ba7a21f189a Author: Michel Normand Date: Tue Jan 19 18:45:10 2010 +0100 lxc: typo in scripts/lxc-debian.in warning with git am, white before tab correction Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit b24319395b9047876e9de03abeb9986441401742 Author: Greg Kurz Date: Tue Jan 19 18:45:13 2010 +0100 lxc: remove useless check The handler argument to lxc_fini() is never null. Signed-off-by: Greg Kurz Signed-off-by: Cedric Le Goater Signed-off-by: Daniel Lezcano commit b79fcd8638b571043610e80bd465adfa9f08842b Author: Greg Kurz Date: Tue Jan 19 18:45:15 2010 +0100 lxc: fix double-close in lxc_[re]spawn() abort path sv[0] has already been closed when reaching out_abort label. Signed-off-by: Greg Kurz Signed-off-by: Cedric Le Goater Signed-off-by: Daniel Lezcano commit 8b7329af3fa876aacd6b0299f4d86e76cd3b14a5 Author: Michel Normand Date: Tue Jan 19 18:45:16 2010 +0100 lxc: add capabilities for C/R Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit c3e13372aaa81587772f6ce9074de6013884a484 Author: Clement Calmels Date: Tue Jan 19 18:45:12 2010 +0100 Remove useless lines Signed-off-by: Clement Calmels Signed-off-by: Cedric Le Goater Signed-off-by: Daniel Lezcano commit 9d7f9e522b87c250178c53ce671f28e3afd73c1e Author: Greg Kurz Date: Tue Jan 19 18:45:14 2010 +0100 lxc: some goto clarification It makes sense to use goto when there's some rollback work to be done. And it's nice for code clarity to add an explicit suffix to goto labels. Signed-off-by: Greg Kurz Signed-off-by: Cedric Le Goater Signed-off-by: Daniel Lezcano commit 79e68309225ef94f3be064276f5f9e285bbcfb0f Author: Michel Normand Date: Tue Jan 19 18:45:11 2010 +0100 lxc: typo white space src/lxc/network.c Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano --- Summary of changes: scripts/lxc-debian.in |2 +- src/lxc/lxc-setcap.in |4 ++-- src/lxc/network.c | 24 src/lxc/start.c | 45 + 4 files changed, 32 insertions(+), 43 deletions(-) hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 267d974e594428bccc1f055c5838ac387777be9f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 267d974e594428bccc1f055c5838ac38be9f (commit) via 96819f4d77ce71f2801d8a589a3ce173f57f0a66 (commit) via 3bc15639ebc2dc46c3eaa915a73c5b07d9ce48eb (commit) via 4357db9a063bd5df3570a1b9ce957253a9d68d40 (commit) from b75afd90891e443f1f9232dc46680ba7a21f189a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 267d974e594428bccc1f055c5838ac38be9f Author: Michel Normand Date: Thu Jan 21 14:34:08 2010 +0100 typo in restart and checkpoint Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 96819f4d77ce71f2801d8a589a3ce173f57f0a66 Author: Michel Normand Date: Thu Jan 21 14:34:08 2010 +0100 lxc-create to run even if not in PATH Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 3bc15639ebc2dc46c3eaa915a73c5b07d9ce48eb Author: Michel Normand Date: Thu Jan 21 14:34:08 2010 +0100 avoid too long line in lxc-busybox.in Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 4357db9a063bd5df3570a1b9ce957253a9d68d40 Author: Michel Normand Date: Thu Jan 21 14:34:08 2010 +0100 add --define to restart V2 Signed-off-by: Cedric Le Goater Signed-off-by: Daniel Lezcano --- Summary of changes: scripts/lxc-busybox.in | 37 ++--- src/lxc/lxc-create.in| 11 ++- src/lxc/lxc.h|4 ++-- src/lxc/lxc_checkpoint.c | 10 -- src/lxc/lxc_restart.c| 12 +++- src/lxc/restart.c|4 ++-- 6 files changed, 59 insertions(+), 19 deletions(-) hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 7674618ce4132f2bc1f3818a181475e58e890bfe
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 7674618ce4132f2bc1f3818a181475e58e890bfe (commit) from 267d974e594428bccc1f055c5838ac38be9f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 7674618ce4132f2bc1f3818a181475e58e890bfe Author: Daniel Lezcano Date: Thu Jan 21 14:45:00 2010 +0100 add extra line in the busybox script A mindless change. Signed-off-by: Daniel Lezcano --- Summary of changes: scripts/lxc-busybox.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 1e11be345d3eeece0df14d6222e1f7baf28933e1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lxc".
The branch, master has been updated
via 1e11be345d3eeece0df14d6222e1f7baf28933e1 (commit)
via 81810dd120291b78daf7c6833e6fcbca0289aad5 (commit)
from 7674618ce4132f2bc1f3818a181475e58e890bfe (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 1e11be345d3eeece0df14d6222e1f7baf28933e1
Author: Daniel Lezcano
Date: Thu Jan 21 15:15:26 2010 +0100
fix tab vs space indentation
Signed-off-by: Daniel Lezcano
commit 81810dd120291b78daf7c6833e6fcbca0289aad5
Author: Daniel Lezcano
Date: Thu Jan 21 14:48:42 2010 +0100
drop capabilities
Hello everyone!
I've written a patch which adds a new config keyword
'lxc.cap.drop'. This keyword allows to specify capabilities which are
dropped before executing the container binary.
Example:
lxc.cap.drop = sys_chroot
lxc.cap.drop = mknod
lxc.cap.drop = sys_module
or specify in a single line:
lxc.cap.drop = sys_chroot mknod sys_module
Reworked-by: Daniel Lezcano
Signed-off-by: Daniel Lezcano
Signed-off-by: Michael Holzt
Signed-off-by: Daniel Lezcano
---
Summary of changes:
doc/lxc.conf.sgml.in | 38 +
src/lxc/conf.c | 91 ++
src/lxc/conf.h |1 +
src/lxc/confile.c| 49 +++
4 files changed, 179 insertions(+), 0 deletions(-)
hooks/post-receive
--
lxc
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. bd288c265ac26dd4a63e7089858ea8f3d78447e6
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via bd288c265ac26dd4a63e7089858ea8f3d78447e6 (commit) via b09094da2d1b08dd912f4c18c3bf0fcfdcbd3652 (commit) from 1e11be345d3eeece0df14d6222e1f7baf28933e1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit bd288c265ac26dd4a63e7089858ea8f3d78447e6 Author: Michel Normand Date: Thu Jan 21 17:21:34 2010 +0100 compilation warning in confile.c Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit b09094da2d1b08dd912f4c18c3bf0fcfdcbd3652 Author: Michel Normand Date: Thu Jan 21 17:21:33 2010 +0100 Add some define to compile on rhel5u1 the last patch commit 81810dd120291b78daf7c6833e6fcbca0289aad5 make lxc to not compile anymore on rhel5u1 Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/conf.c| 16 src/lxc/confile.c |2 +- 2 files changed, 17 insertions(+), 1 deletions(-) hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 7df119eeaead89243486d33339fc039bde0eef04
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lxc".
The branch, master has been updated
via 7df119eeaead89243486d9fc039bde0eef04 (commit)
from bd288c265ac26dd4a63e7089858ea8f3d78447e6 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 7df119eeaead89243486d9fc039bde0eef04
Author: Daniel Lezcano
Date: Fri Jan 22 11:29:10 2010 +0100
unmount failure is not fatal
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
---
Summary of changes:
src/lxc/conf.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
hooks/post-receive
--
lxc
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 9eb09f87215e8df035df975635f8a68b3201a5b1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 9eb09f87215e8df035df975635f8a68b3201a5b1 (commit) from 7df119eeaead89243486d9fc039bde0eef04 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 9eb09f87215e8df035df975635f8a68b3201a5b1 Author: Daniel Lezcano Date: Fri Jan 22 11:45:11 2010 +0100 version 0.6.5 Increment to 0.6.5 version. Signed-off-by: Daniel Lezcano --- Summary of changes: configure.ac |2 +- doc/lxc.conf.sgml.in | 11 +-- 2 files changed, 6 insertions(+), 7 deletions(-) hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc tag, lxc-0.6.5, created. 9eb09f87215e8df035df975635f8a68b3201a5b1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The tag, lxc-0.6.5 has been created at 9eb09f87215e8df035df975635f8a68b3201a5b1 (commit) - Log - commit 9eb09f87215e8df035df975635f8a68b3201a5b1 Author: Daniel Lezcano Date: Fri Jan 22 11:45:11 2010 +0100 version 0.6.5 Increment to 0.6.5 version. Signed-off-by: Daniel Lezcano --- hooks/post-receive -- lxc -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Request for inclusion into mainline LXC utils
Suno Ano wrote: > Hi folks, > > when cloning from [0], there are a bunch of excellent tools like for > example lxc-status. What about including those into mainline lxc utils? > > > [0] git clone git://git.nigel.mcnie.name/lxc-debian.git > I see Nigel McNie is the author of these scripts, it should be Cc'ed no ? -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] fix segfault in capabilities drop code
Sven Wegener wrote: > On Fri, 22 Jan 2010, Sven Wegener wrote: > > >> the capabilities list contains a terminating NULL entry and looping over >> all entries by index results in a segfault on the last entry, if the >> capability in the config is invalid. switch to looping by pointer like >> the mount option code does. >> > > Oops, ignore this one, you fixed it up with the space indentation patch. > Thanks anyway :) -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Request for inclusion into mainline LXC utils
Suno Ano wrote: > Hi folks, > > when cloning from [0], there are a bunch of excellent tools like for > example lxc-status. What about including those into mainline lxc utils? > > > [0] git clone git://git.nigel.mcnie.name/lxc-debian.git Hi guys, there is people writing tools to create the container templates for lxc. * Nigel McNie is writting the lxc-debian and some more scripts: * Guillaume Zitta created a "lxc-provider" project https://sourceforge.net/projects/lxc-provider/ * And I am writing templates to be called by the lxc-create command I was wondering if we can join our effort, as there is a lot of templates to do and different behaviour depending the distros (udev, sysvrc/upstart, mountall, etc ...). And I would like to focus on the lxc core system more than creating templates scripts. Maybe we can elaborate a plan and define an api for the templates scripts to be called by lxc-create and include them in the lxc tree ? Thanks -- Daniel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [patch 3/3][RFC] implement lxc-cmd and lxc-enter using lxc_cinit daemon
Dietmar Maurer wrote: > After locking at the init-logger patches, it seems that it requires a > major rework because the lxc_start code changed quite much. Unfortunately, > I am not too familiar with the current code. > > Daniel, would you mind to rework the old patches to get at least the basic > functionality we had when I submitted the patches? > Dietmar, I was wondering if we shouldn't separate the "init-logger" features. For logging the container output, we can create a tty in lxc-start.c, map the slave endpoint to /dev/console and proxy the master to the real tty. That allows to: * solve the problem of the init process which stole the terminal tty, letting us in a terminal without the controling tty * we can redirect the master to file, a socket, a fifo, etc ... * we reuse most of the lxc-console code In this case, the "init-logger" becomes a "" and we keep separated the feature. What do you think ? -- Daniel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] How to make a container init DIE after finishing runlevel 0
Michael H. Warfield wrote: > On Mon, 2010-01-25 at 23:39 +0100, Daniel Lezcano wrote: > >> Michael H. Warfield wrote: >> >>> On Mon, 2010-01-25 at 21:50 +0100, Daniel Lezcano wrote: >>> >>> >>> >>>>> apologies for the length, but how is everyone else handling this? >>>>> this is the last thing i need to solve before i actually start running >>>>> all my services on this setup. >>>>> >>>>> >>>>> >>>> I was wondering if the kernel shouldn't send a signal to the init's >>>> parent when sys_reboot is called. >>>> >>>> >>> Which still leaves open the question of telling the difference between a >>> halt and a reboot. >>> >> Well, with the correct information in siginfo, that should do the trick: >> > > >> si_num = SIGINFO ? SIGHUP ? >> si_code = SI_KERNEL >> si_int = the "cmd" passed to the reboot (2) function. >> > > I concur that sounds like a good option. But that's a kernel mod and > will require a kernel patch and getting that through the process. Once > that's agreed on that's the route to go, we've got to get the containers > guys involved and get that pushed through. And is this going to work > without any modifications to init itself (per the discussion over on the > -devel list wrt modifications to init and the difficulty and pain of > pulling teeth). What's the next step? > Send a patch with this hack even if it is not the right approach, let's receive some flaming and discuss with containers@/lkml@ about this problem. As I have, one foot in userspace with lxc and another foot in the container kernel development, if we reach a consensus, that should not be a big deal to push upstream a patch, especially if this is a blocker for the container technology. The objective is to have a kernel patch making possible to support the "shutdown / halt / reboot / etc ... " without modifying the init command and compatible with sysv init and upstart. The patch I propose is to send a signal to the parent process of the pid namespace, in our case it's lxc-start. Handling this signal is quite easy as we have just "kill -9" the init process and, in case of a reboot, return to the starting code without exiting lxc-start. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Configuration question?
Michael H. Warfield wrote: > On Tue, 2010-01-26 at 21:18 +0100, Daniel Lezcano wrote: > >> Michael H. Warfield wrote: >> >>> I'm working on some scripts and I have a configuration question. Yes I >>> could probably read the code and figure out the answers for myself or >>> just blindly try it but I figure if I ask here someone could say "no >>> don't do that" or "hey that's not a bad idea" before I go charging >>> ahead. >>> >>> Put simply... Is is possible / permissible to add configuration >>> variables to the config file? I've been converting containers over from >>> OpenVZ and there's some odd flags and values I would like to stuff in >>> there. Things like "ONBOOT" and "DESCRIPTION" from the OpenVZ file. Is >>> lxc-start and friends just going to ignore extraneous (to them) >>> configuration options or are they going to complain or blow chunks? >>> >> It will complain. >> >> >>> If it's possible, is there a convention you would like followed. I'm >>> thinking along this lines of this for those two examples: >>> >>> lxc.onboot = yes|no [default no] >>> lxc.description = "Arbitrary String" >>> >>> Yes? No? Maybe? Hell no? >>> > > >> I am not sure to understand. Can you elaborate a bit ? >> Do you want to define some environment variables for the container via >> the lxc configuration file ? Or are these configuration variables >> specific (I don't know OpenVZ except by its name) ? >> > > OpenVZ supports specifying in their ve config files if a container gets > started when the host is booted. If it's not set, the container won't > get started automatically at boot and has to be manually started. This > would be used by a front end startup script. At boot time, it can check > all the containers registered with it and start the ones set to > autostart. OpenVZ also has a "disabled" option where the container is > disabled even from manual booting unless "force" is specified but I > don't know that I see much use for that. Description is just a high > level description of the container for front ends and user interfaces. > The reason I was thinking of putting it in the config file (which I did > just try just a little bit ago and lxc-start didn't complain, but maybe > it would in a debug print) is that way it would follow the other config > variables when the container is created and I could just loop > through /var/lib/lxc/*/config to find them. > Ok got it, but it's not the right place to put these informations. You can simply add a file /var/lib/lxc/*/onboot, this is the purpose of the lxc directory, store any external information in a single place. So when you destroy the container, the lxc directory is removed with all the external material added at this place. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Configuration question?
Michael H. Warfield wrote: > I'm working on some scripts and I have a configuration question. Yes I > could probably read the code and figure out the answers for myself or > just blindly try it but I figure if I ask here someone could say "no > don't do that" or "hey that's not a bad idea" before I go charging > ahead. > > Put simply... Is is possible / permissible to add configuration > variables to the config file? I've been converting containers over from > OpenVZ and there's some odd flags and values I would like to stuff in > there. Things like "ONBOOT" and "DESCRIPTION" from the OpenVZ file. Is > lxc-start and friends just going to ignore extraneous (to them) > configuration options or are they going to complain or blow chunks? It will complain. > If it's possible, is there a convention you would like followed. I'm > thinking along this lines of this for those two examples: > > lxc.onboot = yes|no [default no] > lxc.description = "Arbitrary String" > > Yes? No? Maybe? Hell no? I am not sure to understand. Can you elaborate a bit ? Do you want to define some environment variables for the container via the lxc configuration file ? Or are these configuration variables specific (I don't know OpenVZ except by its name) ? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [patch] fix improper null termination
Ryousei Takano wrote: > Hi Daniel, > > This patch correctly terminates the string returned by readlink(2) with a > NULL charactor. Good catch. Thanks Ryousei. -- Daniel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Permission of /dev/null to 0600 when booting daemon mode without logging
Ryousei Takano wrote:
> Hi daniel and all,
>
> I have ran the CentOS 5 container on the CentOS 5. When lxc-start executes
> with daemon mode
> and without logging, the permission of /dev/null on the host OS changes from
> 0666 to 0600.
>
> I guess it is because lxc uses bind mount due to remap from /dev/console to
> /dev/null with daemon
> mode. The container OS changes the permission of /dev/console at its boot
> process, and then it
> influences /dev/null on the host OS.
>
> I do not know whether this problem occurs on the other distros.
>
> Here is a simple reproduction code:
>
> #include
> #include
> #include
>
> int
> main()
> {
> /* [LXC] setup_console (lxc/conf.c) */
> if (mount("/dev/null", "/dev/console", "none", MS_BIND, 0)) { /* (1) */
>perror("mount");
>return -1;
> }
> /* [CentOS] ??? */
> if (chmod("/dev/console", 0600)) { /* (2) */
>perror("chmod");
>return -1;
> }
> if (umount("/dev/console")) {
>perror("umount");
>return -1;
> }
> return 0;
> }
>
> Any comments and suggestions will be welcome.
Yeah, I will rewrite the console, it sucks.
I had in mind to allocate a pty and bind mount the client side to the
console and then proxy the master to the controlling tty or another fd
if specified in the command line (file, fifo, socket, etc ...).
I rewrote a part of the lxc-console to implement a couple of functions
to be reused.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
Dominik Schulz wrote: > Am Samstag 30 Januar 2010 21:54:29 schrieb Guillaume ZITTA: >> Sorry for the late response, I was on holidays. >> I do think joining efforts is always a good thing. >> I think some things needs to be defined : >> - best practices for a good container is (no udev, syslog conf...) >> - what minimal features we expect from container creation scripts. >> - who works on it. > Hi, > I'm rather new to LXC but I'm already working on improving the existing tools. > > My work is based on that of Nigel Mcnie [1]. Since he doesn't seem to be > fully involved into LXC I'm looking for a place to contribute my patches to. > > I propose a clear separation of concerns. The core package "lxc" should only > include the essential userland tools, mostly those written in C. I agree. > The fancy ones should go into a package of their own. Either separated by > distribution > (lxc-debian, lxc-redhat, ...) or all in one (lxc-utils). There is too much combination of containers configuration, IMO it should be preferable to keep them separated: lxc-debian (lenny, sid, ...) lxc-fedora (f10, f11, ...) lxc-opensuse (10.1, 11.0, 11.1, ...) lxc-busybox (statically linked or not) That would be nice to identify clearly who handle a script(s). That do not prevent to build on top of these scripts a single one. There is also the sysvrc vs upstart configuration. We have to deal with the host vs container distro too. There is the container configuration itself (eg. macvlan, vlan, veth, etc ... ) to be interactive or not, and the distros configuration (eg. static ip or dhcp). Note people would be interested by templates which are not only distros but also simple applications like sshd or apache+mysql. Why running a full container to host a web browser ? > Further I propose not to separate tools which should be united in one. I'd > like to see the a separation of the container-creation tools based on the > lower level programs they use. Something like lxc-debootstrap for > Debian-based > distributions and something alike for the ones based on RPM. Because > separating Debian and Ubuntu doesn't seem to support achieving our > objectives. > They are just to similar in terms of creating containers. There is the febootstrap command. > (Partly) in contrast to the proposal of Daniel Lezcano [2] I'd propose to > keep > the core utils small and simple (following the well known KISS principle) and > don't go for templates which are called by lxc-create. Instead I'd keep lxc- > create as small as possible and incorporate it into other tools, which I've > mentioned above. That makes senss. Should we have a separate project ? or shall we keep these scripts in the lxc source tree in a different location in order to have the core and the templates synced ? For example, Michael H. Warfield and Tony Risinger are writing some useful scripts to shutdown / reboot the containers, I hope that won't be a third package, so the user will be totally lost. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC container fails to start by complaining that it is unable to unmount the old pivot-root
Andrian Nord wrote: > On Mon, Feb 01, 2010 at 01:54:15PM -0500, Michael H. Warfield wrote: > >> On Mon, 2010-02-01 at 19:46 +0200, Ciprian Dorin, Craciun wrote: >> >>> Hello all! >>> >>> I have a quite strange problem: the container fails to start and >>> complains about being unable to unmount the old pivot root. >>> (What is strange is that I remember that one moth ago the same >>> setup worked (lxc binaries and config file, but maybe 2.6.31 kernel). >>> Now neither the old binaries or the latest ones from Git don't work.) >>> > > Taken from http://blog.flameeyes.eu/2010/01/31/lxc-s-unpolished-code > "So what about the 0.6.5 problem? Well the problem came to be because > 0.6.5 actually implements a nice feature (contributed by a non-core > developer it seems): root pivoting. The idea is to drop access to the > old root, so that the guest cannot in any way access the host’s > filesystem unless given access to. It’s a very good idea, but there are > two problems with it: it doesn’t really do it systematically, but rather > with a “try and hope” approach, and it failed under certain conditions, > saying that the original root is still busy (note here, since this > happens within the cgroup’s mount namespace, it doesn’t matter to the > rest of the system). > > At the end, last night I was able to identify the problem: I had this > line in the fstab file used by lxc itself: > none /tmp tmpfs size=200m 0 0 > > What’s wrong with it? The mountpoint. The fstab (and lxc.mount commands) > are used without previous validation or handling, so this is not > mounting the /tmp for the guest, but the /tmp for the host, within the > guest’s mount namespace. The result is that /tmp gets mounted twice > (once inherited by the base mount namespace, once within the guest’s > namespace, but it’s only unmounted once (as the unmount list keeps each > mount point exactly once). This is quite an obvious error on my part, I > should have used /media/chroots/tinderbox/tmp as mountpoint, but LXC > being unable to catch the mistake in mountpoint (at least warning about > it) is a definite problem." > > That's Gentoo maintainer for lxc ebuilds. May you check if this is > source of the problem? > Ha ! Let's check ! :) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 00/10] new enhancements
* console improvements * shutdown / poweroff / reboot support -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 01/10] fix compilation warning
Add missing include Signed-off-by: Daniel Lezcano --- src/lxc/state.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: lxc/src/lxc/state.c === --- lxc.orig/src/lxc/state.c +++ lxc/src/lxc/state.c @@ -26,7 +26,7 @@ #include #include #include -#include +#include #include #include #include -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 03/10] use a mainloop for the console
Use the mainloop to manage io of the console.
Signed-off-by: Daniel Lezcano
---
src/lxc/lxc_console.c | 163 ++
1 file changed, 88 insertions(+), 75 deletions(-)
Index: lxc/src/lxc/lxc_console.c
===
--- lxc.orig/src/lxc/lxc_console.c
+++ lxc/src/lxc/lxc_console.c
@@ -38,10 +38,10 @@
#include
#include
-#include
-#include
-#include
-
+#include "error.h"
+#include "lxc.h"
+#include "log.h"
+#include "mainloop.h"
#include "arguments.h"
lxc_log_define(lxc_console_ui, lxc_console);
@@ -102,7 +102,7 @@ static void sigwinch(int sig)
static int setup_tios(int fd, struct termios *newtios, struct termios *oldtios)
{
- if (isatty(fd)) {
+ if (!isatty(fd)) {
ERROR("'%d' is not a tty", fd);
return -1;
}
@@ -132,21 +132,68 @@ static int setup_tios(int fd, struct ter
return 0;
}
+static int stdin_handler(int fd, void *data, struct lxc_epoll_descr *descr)
+{
+ static int wait4q = 0;
+ int *peer = (int *)data;
+ char c;
+
+ if (read(0, &c, 1) < 0) {
+ SYSERROR("failed to read");
+ return 1;
+ }
+
+ /* we want to exit the console with Ctrl+a q */
+ if (c == my_args.escape) {
+ wait4q = !wait4q;
+ return 0;
+ }
+
+ if (c == 'q' && wait4q)
+ return 1;
+
+ wait4q = 0;
+ if (write(*peer, &c, 1) < 0) {
+ SYSERROR("failed to write");
+ return 1;
+ }
+
+ return 0;
+}
+
+static int master_handler(int fd, void *data, struct lxc_epoll_descr *descr)
+{
+ char buf[1024];
+ int *peer = (int *)data;
+ int r;
+
+ r = read(fd, buf, sizeof(buf));
+ if (r < 0) {
+ SYSERROR("failed to read");
+ return 1;
+ }
+ write(*peer, buf, r);
+
+ return 0;
+}
+
int main(int argc, char *argv[])
{
- int wait4q = 0;
- int err;
+ int err, std_in = 1;
+ struct lxc_epoll_descr descr;
struct termios newtios, oldtios;
err = lxc_arguments_parse(&my_args, argc, argv);
if (err)
return -1;
- if (lxc_log_init(my_args.log_file, my_args.log_priority,
-my_args.progname, my_args.quiet))
+ err = lxc_log_init(my_args.log_file, my_args.log_priority,
+ my_args.progname, my_args.quiet);
+ if (err)
return -1;
- if (setup_tios(0, &newtios, &oldtios)) {
+ err = setup_tios(0, &newtios, &oldtios);
+ if (err) {
ERROR("failed to setup tios");
return -1;
}
@@ -158,77 +205,47 @@ int main(int argc, char *argv[])
fprintf(stderr, "\nType to exit the console\n",
'a' + my_args.escape - 1);
- if (setsid())
+ err = setsid();
+ if (err)
INFO("already group leader");
if (signal(SIGWINCH, sigwinch) == SIG_ERR) {
SYSERROR("failed to set SIGWINCH handler");
- return -1;
+ err = -1;
+ goto out;
}
winsz();
- err = 0;
+ err = lxc_mainloop_open(&descr);
+ if (err) {
+ ERROR("failed to create mainloop");
+ goto out;
+ }
+
+ err = lxc_mainloop_add_handler(&descr, 0, stdin_handler, &master);
+ if (err) {
+ ERROR("failed to add handler for the stdin");
+ goto out_mainloop_open;
+ }
+
+ err = lxc_mainloop_add_handler(&descr, master, master_handler, &std_in);
+ if (err) {
+ ERROR("failed to add handler for the master");
+ goto out_mainloop_open;
+ }
- /* let's proxy the tty */
- for (;;) {
- struct pollfd pfd[2] = {
- { .fd = 0,
- .events = POLLIN|POLLPRI,
- .revents = 0 },
- { .fd = master,
- .events = POLLIN|POLLPRI,
- .revents = 0 },
- };
-
- if (poll(pfd, 2, -1) < 0) {
- if (errno == EINTR)
- continue;
- SYSERROR("failed to poll");
- goto out_err;
- }
-
- /* read the "stdin" and write that to the master
-*/
- if (pfd[0].revents & POLLIN) {
- char c;
-
[lxc-devel] [patch 04/10] Fix header inclusion
No need to include the lxc_conf structure definition, a forward
declaration is enough.
Signed-off-by: Daniel Lezcano
---
src/lxc/start.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: lxc/src/lxc/start.h
===
--- lxc.orig/src/lxc/start.h
+++ lxc/src/lxc/start.h
@@ -23,14 +23,14 @@
#ifndef __lxc_state_h
#define __lxc_state_h
-#include
#include
+#include
-struct lxc_handler {
+struct lxc_conf;
+struct lxc_handler {
pid_t pid;
lxc_state_t state;
-
int sigfd;
char nsgroup[MAXPATHLEN];
sigset_t oldmask;
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 02/10] factor-out-console code
Factore out the console code and encapsulate the code in
functions.
Signed-off-by: Daniel Lezcano
---
src/lxc/lxc_console.c | 67 --
1 file changed, 43 insertions(+), 24 deletions(-)
Index: lxc/src/lxc/lxc_console.c
===
--- lxc.orig/src/lxc/lxc_console.c
+++ lxc/src/lxc/lxc_console.c
@@ -100,11 +100,43 @@ static void sigwinch(int sig)
winsz();
}
+static int setup_tios(int fd, struct termios *newtios, struct termios *oldtios)
+{
+ if (isatty(fd)) {
+ ERROR("'%d' is not a tty", fd);
+ return -1;
+ }
+
+ /* Get current termios */
+ if (tcgetattr(0, oldtios)) {
+ SYSERROR("failed to get current terminal settings");
+ return -1;
+ }
+
+ *newtios = *oldtios;
+
+ /* Remove the echo characters and signal reception, the echo
+* will be done below with master proxying */
+ newtios->c_iflag &= ~IGNBRK;
+ newtios->c_iflag &= BRKINT;
+ newtios->c_lflag &= ~(ECHO|ICANON|ISIG);
+ newtios->c_cc[VMIN] = 1;
+ newtios->c_cc[VTIME] = 0;
+
+ /* Set new attributes */
+ if (tcsetattr(0, TCSAFLUSH, newtios)) {
+ ERROR("failed to set new terminal settings");
+ return -1;
+ }
+
+ return 0;
+}
+
int main(int argc, char *argv[])
{
int wait4q = 0;
int err;
- struct termios tios, oldtios;
+ struct termios newtios, oldtios;
err = lxc_arguments_parse(&my_args, argc, argv);
if (err)
@@ -114,27 +146,8 @@ int main(int argc, char *argv[])
my_args.progname, my_args.quiet))
return -1;
- /* Get current termios */
- if (tcgetattr(0, &tios)) {
- ERROR("failed to get current terminal settings : %s",
- strerror(errno));
- return -1;
- }
-
- oldtios = tios;
-
- /* Remove the echo characters and signal reception, the echo
-* will be done below with master proxying */
- tios.c_iflag &= ~IGNBRK;
- tios.c_iflag &= BRKINT;
- tios.c_lflag &= ~(ECHO|ICANON|ISIG);
- tios.c_cc[VMIN] = 1;
- tios.c_cc[VTIME] = 0;
-
- /* Set new attributes */
- if (tcsetattr(0, TCSAFLUSH, &tios)) {
- ERROR("failed to set new terminal settings : %s",
- strerror(errno));
+ if (setup_tios(0, &newtios, &oldtios)) {
+ ERROR("failed to setup tios");
return -1;
}
@@ -145,8 +158,14 @@ int main(int argc, char *argv[])
fprintf(stderr, "\nType to exit the console\n",
'a' + my_args.escape - 1);
- setsid();
- signal(SIGWINCH, sigwinch);
+ if (setsid())
+ INFO("already group leader");
+
+ if (signal(SIGWINCH, sigwinch) == SIG_ERR) {
+ SYSERROR("failed to set SIGWINCH handler");
+ return -1;
+ }
+
winsz();
err = 0;
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 07/10] count the number of tasks in the container
This patch adds a function to count the number of tasks in the
container.
Signed-off-by: Daniel Lezcano
---
src/lxc/cgroup.c | 27 +++
src/lxc/cgroup.h |2 +-
2 files changed, 28 insertions(+), 1 deletion(-)
Index: lxc/src/lxc/cgroup.c
===
--- lxc.orig/src/lxc/cgroup.c
+++ lxc/src/lxc/cgroup.c
@@ -219,3 +219,30 @@ int lxc_cgroup_get(const char *name, con
close(fd);
return ret;
}
+
+int lxc_cgroup_nrtasks(const char *name)
+{
+ char *nsgroup;
+ char path[MAXPATHLEN];
+ int pid, ret, count = 0;
+ FILE *file;
+
+ ret = lxc_cgroup_path_get(&nsgroup, name);
+ if (ret)
+ return -1;
+
+snprintf(path, MAXPATHLEN, "%s/tasks", nsgroup);
+
+ file = fopen(path, "r");
+ if (!file) {
+ SYSERROR("fopen '%s' failed", path);
+ return -1;
+ }
+
+ while (fscanf(file, "%d", &pid) != EOF)
+ count++;
+
+ fclose(file);
+
+ return count;
+}
Index: lxc/src/lxc/cgroup.h
===
--- lxc.orig/src/lxc/cgroup.h
+++ lxc/src/lxc/cgroup.h
@@ -29,5 +29,5 @@ struct lxc_handler;
int lxc_rename_nsgroup(const char *name, struct lxc_handler *handler);
int lxc_unlink_nsgroup(const char *name);
int lxc_cgroup_path_get(char **path, const char *name);
-
+int lxc_cgroup_nrtasks(const char *name);
#endif
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 05/10] rename network type enum
Use a prefixed enum to avoid conflict later.
Signed-off-by: Daniel Lezcano
---
src/lxc/conf.c| 14 +++---
src/lxc/conf.h| 12 ++--
src/lxc/confile.c | 10 +-
3 files changed, 18 insertions(+), 18 deletions(-)
Index: lxc/src/lxc/conf.c
===
--- lxc.orig/src/lxc/conf.c
+++ lxc/src/lxc/conf.c
@@ -104,12 +104,12 @@ static int instanciate_vlan(struct lxc_n
static int instanciate_phys(struct lxc_netdev *);
static int instanciate_empty(struct lxc_netdev *);
-static instanciate_cb netdev_conf[MAXCONFTYPE + 1] = {
- [VETH]= instanciate_veth,
- [MACVLAN] = instanciate_macvlan,
- [VLAN]= instanciate_vlan,
- [PHYS]= instanciate_phys,
- [EMPTY] = instanciate_empty,
+static instanciate_cb netdev_conf[LXC_NET_MAXCONFTYPE + 1] = {
+ [LXC_NET_VETH]= instanciate_veth,
+ [LXC_NET_MACVLAN] = instanciate_macvlan,
+ [LXC_NET_VLAN]= instanciate_vlan,
+ [LXC_NET_PHYS]= instanciate_phys,
+ [LXC_NET_EMPTY] = instanciate_empty,
};
static struct mount_opt mount_opt[] = {
@@ -1241,7 +1241,7 @@ int lxc_create_network(struct lxc_list *
netdev = iterator->elem;
- if (netdev->type < 0 || netdev->type > MAXCONFTYPE) {
+ if (netdev->type < 0 || netdev->type > LXC_NET_MAXCONFTYPE) {
ERROR("invalid network configuration type '%d'",
netdev->type);
return -1;
Index: lxc/src/lxc/conf.h
===
--- lxc.orig/src/lxc/conf.h
+++ lxc/src/lxc/conf.h
@@ -29,12 +29,12 @@
#include
enum {
- EMPTY,
- VETH,
- MACVLAN,
- PHYS,
- VLAN,
- MAXCONFTYPE,
+ LXC_NET_EMPTY,
+ LXC_NET_VETH,
+ LXC_NET_MACVLAN,
+ LXC_NET_PHYS,
+ LXC_NET_VLAN,
+ LXC_NET_MAXCONFTYPE,
};
/*
Index: lxc/src/lxc/confile.c
===
--- lxc.orig/src/lxc/confile.c
+++ lxc/src/lxc/confile.c
@@ -132,15 +132,15 @@ static int config_network_type(const cha
lxc_list_add(network, list);
if (!strcmp(value, "veth"))
- netdev->type = VETH;
+ netdev->type = LXC_NET_VETH;
else if (!strcmp(value, "macvlan"))
- netdev->type = MACVLAN;
+ netdev->type = LXC_NET_MACVLAN;
else if (!strcmp(value, "vlan"))
- netdev->type = VLAN;
+ netdev->type = LXC_NET_VLAN;
else if (!strcmp(value, "phys"))
- netdev->type = PHYS;
+ netdev->type = LXC_NET_PHYS;
else if (!strcmp(value, "empty"))
- netdev->type = EMPTY;
+ netdev->type = LXC_NET_EMPTY;
else {
ERROR("invalid network type %s", value);
return -1;
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 06/10] allocate a console to be proxied
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=
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:
tail --retry -f /var/lib/lxc/foo/console
in another shell:
lxc-start -n foo -s lxc.console=$(tty)
Signed-off-by: Daniel Lezcano
---
src/lxc/conf.c | 56 +++-
src/lxc/conf.h | 30 ---
src/lxc/confile.c | 20 +
src/lxc/console.c | 80 +++-
src/lxc/console.h | 26
src/lxc/lxc_start.c | 45 -
src/lxc/start.c | 78 --
7 files changed, 200 insertions(+), 135 deletions(-)
Index: lxc/src/lxc/conf.c
===
--- lxc.orig/src/lxc/conf.c
+++ lxc/src/lxc/conf.c
@@ -641,41 +641,42 @@ out:
return 0;
}
-static int setup_console(const char *rootfs, const char *tty)
+static int setup_console(const char *rootfs, const struct lxc_console *console)
{
- char console[MAXPATHLEN];
+ char path[MAXPATHLEN];
+ struct stat s;
- snprintf(console, sizeof(console), "%s/dev/console",
-rootfs ? rootfs : "");
-
- /* we have the rootfs with /dev/console but no tty
-* to be used as console, let's remap /dev/console
-* to /dev/null to avoid to log to the system console
-*/
- if (rootfs && !tty[0]) {
+ /* We don't have a rootfs, /dev/console will be shared */
+ if (!rootfs)
+ return 0;
- if (!access(console, F_OK)) {
+ snprintf(path, sizeof(path), "%s/dev/console", rootfs);
- if (mount("/dev/null", console, "none", MS_BIND, 0)) {
- SYSERROR("failed to mount '/dev/null'->'%s'",
-console);
- return -1;
- }
- }
+ if (access(path, F_OK)) {
+ WARN("rootfs specified but no console found");
+ return 0;
}
- if (!tty[0])
- return 0;
+ if (console->peer == -1)
+ INFO("no console output required");
- if (access(console, R_OK|W_OK))
- return 0;
+ if (stat(path, &s)) {
+ SYSERROR("failed to stat '%s'", path);
+ return -1;
+ }
+
+ if (chmod(console->name, s.st_mode)) {
+ SYSERROR("failed to set mode '0%o' to '%s'",
+s.st_mode, console->name);
+ return -1;
+ }
- if (mount(tty, console, "none", MS_BIND, 0)) {
- ERROR("failed to mount the console");
+ if (mount(console->name, path, "none", MS_BIND, 0)) {
+ ERROR("failed to mount '%s' on '%s'", console->name, path);
return -1;
}
- INFO("console '%s' mounted to '%s'", tty, console);
+ INFO("console has been setup");
return 0;
}
@@ -1073,7 +1074,10 @@ struct lxc_conf *lxc_conf_init(void)
new->utsname = NULL;
new->tty = 0;
new->pts = 0;
- new->console[0] = '\0';
+ new->console.peer = -1;
+ new->console.master = -1;
+ new->console.slave = -1;
+ new->console.name[0] = '\0';
lxc_list_init(&new->cgroup);
lxc_list_init(&new->network);
lxc_list_init(&new->mount_list);
@@ -1361,7 +1365,7 @@ int lxc_setup(const char *name, struct l
return -1;
}
- if (setup_console(lxc_conf->rootfs, lxc_conf->console)) {
+ if (setup_console(lxc_conf->rootfs, &lxc_conf->console)) {
ERROR("failed to setup the console for '%s'", name);
ret
[lxc-devel] [patch 08/10] Store the container name in the handler
Store the container in the handler, so it is accessible
everywhere.
Signed-off-by: Daniel Lezcano
---
src/lxc/start.c | 12 +++-
src/lxc/start.h |1 +
2 files changed, 12 insertions(+), 1 deletion(-)
Index: lxc/src/lxc/start.c
===
--- lxc.orig/src/lxc/start.c
+++ lxc/src/lxc/start.c
@@ -196,10 +196,16 @@ struct lxc_handler *lxc_init(const char
handler->conf = conf;
+ handler->name = strdup(name);
+ if (!handler->name) {
+ ERROR("failed to allocate memory");
+ goto out_free;
+ }
+
/* Begin the set the state to STARTING*/
if (lxc_set_state(name, handler, STARTING)) {
ERROR("failed to set state '%s'", lxc_state2str(STARTING));
- goto out_free;
+ goto out_free_name;
}
if (lxc_create_tty(name, conf)) {
@@ -234,6 +240,9 @@ out_delete_tty:
lxc_delete_tty(&conf->tty_info);
out_aborting:
lxc_set_state(name, handler, ABORTING);
+out_free_name:
+ free(handler->name);
+ handler->name = NULL;
out_free:
free(handler);
return NULL;
@@ -249,6 +258,7 @@ void lxc_fini(const char *name, struct l
lxc_unlink_nsgroup(name);
lxc_delete_tty(&handler->conf->tty_info);
+ free(handler->name);
free(handler);
LXC_TTY_DEL_HANDLER(SIGQUIT);
Index: lxc/src/lxc/start.h
===
--- lxc.orig/src/lxc/start.h
+++ lxc/src/lxc/start.h
@@ -30,6 +30,7 @@ struct lxc_conf;
struct lxc_handler {
pid_t pid;
+ char *name;
lxc_state_t state;
int sigfd;
char nsgroup[MAXPATHLEN];
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [patch 10/10] reboot the container at reboot
When the reboot is detected, reboot the container.
Signed-off-by: Daniel Lezcano
---
src/lxc/commands.c |7 +++
src/lxc/conf.c |6 --
src/lxc/conf.h |1 +
src/lxc/confile.c | 30 +++---
src/lxc/lxc.h |3 ++-
src/lxc/lxc_start.c | 19 ++-
src/lxc/start.c |3 +++
src/lxc/utmp.c |3 ++-
8 files changed, 52 insertions(+), 20 deletions(-)
Index: lxc/src/lxc/commands.c
===
--- lxc.orig/src/lxc/commands.c
+++ lxc/src/lxc/commands.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -228,6 +229,12 @@ extern int lxc_command_mainloop_add(cons
return -1;
}
+ if (fcntl(fd, F_SETFD, FD_CLOEXEC)) {
+ SYSERROR("failed to set sigfd to close-on-exec");
+ close(fd);
+ return -1;
+ }
+
ret = lxc_mainloop_add_handler(descr, fd, incoming_command_handler,
handler);
if (ret) {
ERROR("failed to add handler for command socket");
Index: lxc/src/lxc/lxc.h
===
--- lxc.orig/src/lxc/lxc.h
+++ lxc/src/lxc/lxc.h
@@ -43,9 +43,10 @@ struct lxc_conf;
* Start the specified command inside a container
* @name : the name of the container
* @argv : an array of char * corresponding to the commande line
+ * @conf : configuration
* Returns 0 on sucess, < 0 otherwise
*/
-extern int lxc_start(const char *name, char *const argv[], struct lxc_conf *);
+extern int lxc_start(const char *name, char *const argv[], struct lxc_conf
*conf);
/*
* Stop the container previously started with lxc_start, all
Index: lxc/src/lxc/lxc_start.c
===
--- lxc.orig/src/lxc/lxc_start.c
+++ lxc/src/lxc/lxc_start.c
@@ -90,17 +90,15 @@ Options :\n\
int main(int argc, char *argv[])
{
- char *const *args;
int err = -1;
-
+ struct lxc_conf *conf;
+ char *const *args;
+ char *rcfile = NULL;
char *const default_args[] = {
"/sbin/init",
'\0',
};
- char *rcfile = NULL;
- struct lxc_conf *conf;
-
lxc_list_init(&defines);
if (lxc_arguments_parse(&my_args, argc, argv))
@@ -176,6 +174,17 @@ int main(int argc, char *argv[])
err = lxc_start(my_args.name, args, conf);
+ /*
+* exec ourself, that requires to have all opened fd
+* with the close-on-exec flag set
+*/
+ if (conf->reboot) {
+ INFO("rebooting container");
+ execvp(argv[0], argv);
+ SYSERROR("failed to exec");
+ err = -1;
+ }
+
return err;
}
Index: lxc/src/lxc/start.c
===
--- lxc.orig/src/lxc/start.c
+++ lxc/src/lxc/start.c
@@ -471,6 +471,9 @@ int lxc_start(const char *name, char *co
while (waitpid(handler->pid, &status, 0) < 0 && errno == EINTR)
continue;
+ if (sigprocmask(SIG_SETMASK, &handler->oldmask, NULL))
+ WARN("failed to restore sigprocmask");
+
err = lxc_error_set_and_log(handler->pid, status);
out_fini:
lxc_fini(name, handler);
Index: lxc/src/lxc/utmp.c
===
--- lxc.orig/src/lxc/utmp.c
+++ lxc/src/lxc/utmp.c
@@ -94,7 +94,8 @@ static int utmp_handler(int fd, void *da
}
if (currun_level == '6') {
- INFO("container has reboot");
+ INFO("container has rebooted");
+ conf->reboot = 1;
kill(handler->pid, SIGKILL);
}
}
Index: lxc/src/lxc/conf.c
===
--- lxc.orig/src/lxc/conf.c
+++ lxc/src/lxc/conf.c
@@ -1068,12 +1068,6 @@ struct lxc_conf *lxc_conf_init(void)
}
memset(new, 0, sizeof(*new));
- new->rootfs = NULL;
- new->pivotdir = NULL;
- new->fstab = NULL;
- new->utsname = NULL;
- new->tty = 0;
- new->pts = 0;
new->console.peer = -1;
new->console.master = -1;
new->console.slave = -1;
Index: lxc/src/lxc/conf.h
===
--- lxc.orig/src/lxc/conf.h
+++ lxc/src/lxc/conf.h
@@ -181,6 +181,7 @@ struct lxc_conf {
char *fstab;
int tty;
int pts;
+ int reboot;
struct utsname *utsname;
struct lxc_list cgroup;
struct lxc_list network;
Index: lxc/src/lxc/confile.c
[lxc-devel] [patch 09/10] shutdown container when powering off the container
This patch allows to shutdown the container when the system
is powered off in the container.
Signed-off-by: Daniel Lezcano
---
src/lxc/Makefile.am |6 +-
src/lxc/start.c | 11 +++
src/lxc/utmp.c | 156
src/lxc/utmp.h | 28 +
4 files changed, 198 insertions(+), 3 deletions(-)
Index: lxc/src/lxc/Makefile.am
===
--- lxc.orig/src/lxc/Makefile.am
+++ lxc/src/lxc/Makefile.am
@@ -18,7 +18,7 @@ so_PROGRAMS = liblxc.so
liblxc_so_SOURCES = \
arguments.c arguments.h \
commands.c commands.h \
- start.c \
+ start.c start.h \
stop.c \
monitor.c monitor.h \
console.c \
@@ -43,7 +43,9 @@ liblxc_so_SOURCES = \
genl.c genl.h \
\
mainloop.c mainloop.h \
- af_unix.c af_unix.h
+ af_unix.c af_unix.h \
+ \
+ utmp.c utmp.h
AM_CFLAGS=-I$(top_srcdir)/src
Index: lxc/src/lxc/start.c
===
--- lxc.orig/src/lxc/start.c
+++ lxc/src/lxc/start.c
@@ -91,10 +91,12 @@ int signalfd(int fd, const sigset_t *mas
#include "start.h"
#include "conf.h"
#include "log.h"
+#include "cgroup.h"
#include "error.h"
#include "af_unix.h"
#include "mainloop.h"
#include "utils.h"
+#include "utmp.h"
#include "monitor.h"
#include "commands.h"
#include "console.h"
@@ -172,8 +174,15 @@ int lxc_poll(const char *name, struct lx
goto out_mainloop_open;
}
- if (lxc_command_mainloop_add(name, &descr, handler))
+ if (lxc_command_mainloop_add(name, &descr, handler)) {
+ ERROR("failed to add command handler to mainloop");
goto out_mainloop_open;
+ }
+
+ if (lxc_utmp_mainloop_add(&descr, handler)) {
+ ERROR("failed to add utmp handler to mainloop");
+ goto out_mainloop_open;
+ }
return lxc_mainloop(&descr);
Index: lxc/src/lxc/utmp.c
===
--- /dev/null
+++ lxc/src/lxc/utmp.c
@@ -0,0 +1,156 @@
+/*
+ * lxc: linux Container library
+ *
+ * (C) Copyright IBM Corp. 2007, 2008
+ *
+ * Authors:
+ * Daniel Lezcano
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "conf.h"
+#include "cgroup.h"
+#include "start.h"
+#include "mainloop.h"
+#include "lxc.h"
+#include "log.h"
+#define __USE_GNU
+#include
+#undef __USE_GNU
+
+lxc_log_define(lxc_utmp, lxc);
+
+static int utmp_handler(int fd, void *data, struct lxc_epoll_descr *descr)
+{
+ struct inotify_event ie;
+ struct utmpx *utmpx;
+ struct lxc_handler *handler = (struct lxc_handler *)data;
+ struct lxc_conf *conf = handler->conf;
+ char prevrun_level = 'N', currun_level = 'N';
+ int ntasks, ret;
+ char path[MAXPATHLEN];
+
+ if (read(fd, &ie, sizeof(ie)) < 0) {
+ SYSERROR("failed to read utmp notification");
+ return -1;
+ }
+
+ if (snprintf(path, MAXPATHLEN, "%s/var/run/utmp", conf->rootfs) >
+ MAXPATHLEN) {
+ ERROR("path is too long");
+ return -1;
+ }
+
+ if (utmpxname(path)) {
+ SYSERROR("failed to 'utmpxname'");
+ return -1;
+ }
+
+ setutxent();
+
+ while ((utmpx = getutxent())) {
+
+ if (utmpx->ut_type == RUN_LVL) {
+ prevrun_level = utmpx->ut_pid / 256;
+ currun_level = utmpx->ut_pid % 256;
+ }
+ }
+
+ ntasks = lxc_cgroup_nrtasks(handler->name);
+ if (ntasks < 0) {
+ ERROR("failed to get the number of tasks");
+ goto out;
+ }
+
+ if (ntasks == 1 && prevrun_level == '3') {
+
+
Re: [lxc-devel] mounting filesystems in a container
Michael Tokarev wrote: > I've a question here. > > What's a way to mont a new filesystem within a > container, besides re-starting the container? > > For example, I've inserted a removable media on the > host, it's available on the host as /dev/sdb1, and is > mounted on the host as /mnt/removable. But how to > make it available in a running container? > > The same question pops up when I create a new filesystem > on host (parted + fsck etc). > > Initially I had a need to re-arrange partitions/filesystems > to make some more room available for certain containers, > un-mounting things from within containers in order to re- > format filesystem works, but mounting it again does not. > > Or am I missing something? > > (the block device, /dev/sdb1 in that case, is not accessible > to the container in question using lxc.cgroup.devices.deny). > I never tried but I think this is possible with mount propagation via the shared-subtree. AFAIR, that was added to the mount namespace, especially for the use case you are giving. http://www.ibm.com/developerworks/linux/library/l-mount-namespaces.html http://lwn.net/Articles/159092/ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] read-only container root
Michael Tokarev wrote: > lxc-start: No such file or directory - failed to mount a new instance of > '/dev/pts' > I'm experimenting with a read-only root fs in the container. > So far it does not work. > > 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. > Why do you need to use a read-only root fs ? > 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' > It's a bug introduced with the pivot_root feature. Investigation on the way. > Ok, so far so "good". > > Next thing is the /dev directory. I prefer to have it in a tmpfs, because > of several reasons (one is that the root is mounted with -o nodev), but that > fails too unless the directory is pre-populated: > > lxc-start: No such file or directory - failed to mount a new instance of > '/dev/pts' > lxc-start: failed to setup the new pts instance > > That's when specifying: > >lxc.mount.entry = /dev dev tmpfs noexec,nosuid,mode=0755 > > in the config file. That creates an empty directory for container's /dev, > which is populated later in the startup script. > > Similar thing happens when I pre-create dev/pts - it fails to bind-mount > tty1..tty4. > Ok, so your need is to call a script between: lxc.mount.entry = /dev dev tmpfs noexec,nosuid,mode=0755 ... lxc.tty = 4 where the script will populate /dev, right ? mmh, not obvious. > So far it works by using a wrapper around lxc-start which mounts tmpfs > over dev, fills it with a bunch of standard entries, and executes lxc-start. > > But this is really getting quite ugly. And the only solution to all this > mess is to let to perform the setup from a shell script/command which is > called after "forking" the (filesystem) namespace but before entering the > container "for real", or _instead_ of entering the container. As was > discussed previously. > What about the lxc.script configuration line which calls a script at the point it is in the configuration file ? > The whole mess started when I realized that bind-mounting host's /dev > works perfectly _except_ the syslogging, -- /dev/log does not work with > multiple containers, only the container where syslogd (re)started last > works, all the rest gives "ECONNREFUSED" when trying to send any message > to /dev/log. > /dev/log is an af_unix socket, the network is isolated, the af_unix belongs to the network namespace. It's probable /dev/log is unlinked, created again and binded by syslogd. So as /dev/ is shared between the containers, the last one get the socket. Any process outside of the container trying to access this socket won't be able. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] read-only container root
Michael Tokarev wrote: > Daniel Lezcano wrote: >> Michael Tokarev wrote: >>> lxc-start: No such file or directory - failed to mount a new >>> instance of '/dev/pts' >>> I'm experimenting with a read-only root fs in the container. >>> So far it does not work. >>> >>> 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. >>> >> Why do you need to use a read-only root fs ? > > There's no _need_, but it's an extension on a principle of least > privilege, and also helps keeping things in a more accurate way > and also guarantees that no bad things will happen with the system > in case of any unexpected power failure and things like that (in > that case, say, /var might be badly damaged still, but the system > will actually boot to the point where some repairment tools are > available). Agree, that makes sense. >>> 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... > [] >> It's a bug introduced with the pivot_root feature. Investigation on >> the way. > > I tried to debug it too, but realized that the last git repo I have > locally is from 22th Jan, which is almost a month from now, and I've > seen quite some changes mentioned on the list. So it is either that > the changes hasn't been comitted, or the git repository has been > moved somewhere else. It actually was my 3rd email I planned to > write, asking what's up with the git repo... ;) No, the repo is still there but at the moment I am very busy, so I didn't pushed the patches to the git tree. There is a pending patches to fix a readlink I didn't took because the patchset I am about to commit removes this code. The pending patchset is the fix of the console as I mentioned some weeks ago when I said the console sucks and the shutdown / reboot support. I sent the patchset, but as nobody commented it, I supposed no hurry for it. > [] >> Ok, so your need is to call a script between: >> >> lxc.mount.entry = /dev dev tmpfs noexec,nosuid,mode=0755 >> >> ... >> lxc.tty = 4 >> >> where the script will populate /dev, right ? >> >> mmh, not obvious. > > Or maybe just call it _instead_ of specifying all the > above (lxc.mount.entry and lxc.tty), leaving only things > such as network device setup (which can't easily be done > from shell) to lxc-start. The console ttys are created outside of the container and the /dev/pts/X is bind mounted on $rootfs/dev/ttyY - if this option is not set you won't have the tty - if this option is set but /dev is not yet populated (no /dev/ttyY) the tty creation will fail. This is for this reason I proposed this feature which is though to implement, but maybe it's overkill. Otherwise, nothing prevent to create a configuration file with only the network and call a script doing all the configuration, for example: #!/bin/sh ip addr add ... route add ... mount chroot $rootfs exec /sbin/init And then call lxc-start -n mycontainer mylauncher.sh no ? > [] >> What about the lxc.script configuration line which calls a script at >> the point it is in the configuration file ? > > That's not possible. The configuration is an _unordered_ set > of key=value pairs. lxc-start calls different functions now > at pre-defined (programmatically) order, regardless of the > order in which the config file is written. > > The specified script (lxc.script) should also be called at some > (random) pre-determined point in the container setup procedure. > In that case the script can _replace_ some things from the > config file if they're at "wrong" order or are staying in > the way. But it's still not obvious where's that "random" > place is: for example, is it before lxc-start (implicitly!) > mounts /dev/pts or after? For my example the script should > run before /dev/pts is mounted, but maybe someone will want > to run some other program that uses pseudo-t
[lxc-devel] [GIT] lxc branch, master, updated. c08556c6ece8ad8308f7636adb0ad25b60e3a16d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via c08556c6ece8ad8308f7636adb0ad25b60e3a16d (commit) via 1560f6c9a7c822fd625914eefa0b985f67d76a0a (commit) via e0dc0de76ed1ad9e284a37bd01268227d4eae8c9 (commit) via 63376d7db32acf2f8582627e5ff01d8d3f0d46d1 (commit) via 246541036cf5434749d91a566b70b7ddcdb294bd (commit) via 872e18998b723779e1e1b36130bc28e438bd9d1e (commit) via 7ee5bb5583abe0821780c2056c0dfff3444a4fdc (commit) via 6dae68151518a26f87169cf0d3bb2fd39624b75c (commit) via 236087a6c8791f1ade2f80e8ed89712eee161d3f (commit) via 90b59fd059e0c08a5ad3c598fdf6e8758ab10582 (commit) via ef184f8c54534c38ac52dd84f46af0e624aa12f0 (commit) from 9eb09f87215e8df035df975635f8a68b3201a5b1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit c08556c6ece8ad8308f7636adb0ad25b60e3a16d Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 use lazy umount when umount returns EBUSY When the umount fails, we force the umount and make the mount point unaccessible by using a lazy umount. Signed-off-by: Daniel Lezcano commit 1560f6c9a7c822fd625914eefa0b985f67d76a0a Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 fix no rootfs no console When there is no rootfs, don't create a console. Signed-off-by: Daniel Lezcano commit e0dc0de76ed1ad9e284a37bd01268227d4eae8c9 Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 set terminal settings when console is a tty 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 commit 63376d7db32acf2f8582627e5ff01d8d3f0d46d1 Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 allocate a console to be proxied 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= 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 commit 246541036cf5434749d91a566b70b7ddcdb294bd Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 rename network type enum Use a prefixed enum to avoid conflict later. Signed-off-by: Daniel Lezcano commit 872e18998b723779e1e1b36130bc28e438bd9d1e Author: Daniel Lezcano Date: Wed Feb 24 10:57:43 2010 +0100 Fix header inclusion No need to include the lxc_conf structure definition, a forward declaration is enough. Signed-off-by: Daniel Lezcano commit 7ee5bb5583abe0821780c2056c0dfff3444a4fdc Author: Daniel Lezcano Date: Wed Feb 24 10:57:42 2010 +0100 use a mainloop for the console Use the mainloop to manage io of the console. Signed-off-by: Daniel Lezcano commit 6dae68151518a26f87169cf0d3bb2fd39624b75c Author: Daniel Lezcano Date: Wed Feb 24 10:57:42 2010 +0100 factor-out-console code Factor out the console code and encapsulate the code in functions. Signed-off-by: Daniel Lezcano commit 236087a6c8791f1ade2f80e8ed89712eee161d3f Author: Daniel Lezcano Date: Wed Feb 24 10:57:42 2010 +0100 fix empty network namespace When there is an empty network namespace, we must not move the network device. Signed-off-by: Daniel Lezcano commit 90b59fd059e0c08a5ad3c598fdf6e8758ab10582 Author: Daniel Lezcano Date: Wed Feb 24 10:57:42 2010 +0100 fix compilation warning Add missing include Signed-off-by: Daniel L
[lxc-devel] [GIT] lxc branch, master, updated. 6a3111b87e838561db952255a3770a1e85eb361b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 6a3111b87e838561db952255a3770a1e85eb361b (commit) via b4f8660eb27d0a93fa23e13795e53d34c5fd8538 (commit) from c08556c6ece8ad8308f7636adb0ad25b60e3a16d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 6a3111b87e838561db952255a3770a1e85eb361b Author: Daniel Lezcano Date: Wed Feb 24 16:24:55 2010 +0100 add missing cgroup include 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 commit b4f8660eb27d0a93fa23e13795e53d34c5fd8538 Author: Silas Sewell Date: Wed Feb 24 16:24:55 2010 +0100 Add missing stat.h include to start.c The patch fixes a build error on the devel version of Fedora. Signed-off-by: Silas Sewell Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/start.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) hooks/post-receive -- lxc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 7fef7a06d809334b178f76630bb10faa16dc58c0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 7fef7a06d809334b178f76630bb10faa16dc58c0 (commit) via c547a83527cb88bede0ccc323b79145d225da2d0 (commit) via b9a5bb586c0abbdb315573b201703c1f0bcfe25c (commit) from 6a3111b87e838561db952255a3770a1e85eb361b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 7fef7a06d809334b178f76630bb10faa16dc58c0 Author: Daniel Lezcano Date: Thu Feb 25 10:24:13 2010 +0100 fix network devices cleanup on error 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 commit c547a83527cb88bede0ccc323b79145d225da2d0 Author: Daniel Lezcano Date: Thu Feb 25 10:24:13 2010 +0100 fix function prototype implementation Fix inconsistent function definition regarding the headers. Signed-off-by: Daniel Lezcano commit b9a5bb586c0abbdb315573b201703c1f0bcfe25c Author: Daniel Lezcano Date: Thu Feb 25 10:24:12 2010 +0100 delete network devices by index Add a function to delete the network device by its index. Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/conf.c| 12 src/lxc/conf.h|1 + src/lxc/network.c | 40 ++-- src/lxc/network.h |5 + src/lxc/start.c | 11 +++ 5 files changed, 63 insertions(+), 6 deletions(-) hooks/post-receive -- lxc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 7d9fb3e9d2b9722040f37f0e01e29d071f4c6fe8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 7d9fb3e9d2b9722040f37f0e01e29d071f4c6fe8 (commit) via d45fdd27079a7601c3a285f64d42588449746ff0 (commit) from 7fef7a06d809334b178f76630bb10faa16dc58c0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 7d9fb3e9d2b9722040f37f0e01e29d071f4c6fe8 Author: Daniel Lezcano Date: Fri Feb 26 21:12:31 2010 +0100 fix kill -1 process 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 commit d45fdd27079a7601c3a285f64d42588449746ff0 Author: Daniel Lezcano Date: Fri Feb 26 21:12:31 2010 +0100 add console.h to dist file Add the console.h file in order to compile the dist file. Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/Makefile.am |1 + src/lxc/start.c |3 ++- 2 files changed, 3 insertions(+), 1 deletions(-) hooks/post-receive -- lxc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] mounting a crypted volume in a container
l...@zitta.fr wrote: > hi, > > I'm trying to provide a crypted volume to a container : > - So i have added it to the container's fstab : > r...@ksxxx:~# cat /var/lib/lxc/newzer.ovh2.p.zitta.fr/fstab > /lxc/root/newzer.ovh2.p.zitta.fr > /var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs none rbind 0 0 > /dev/mapper/crypt_newzer > /var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs/home ext4 defaults 0 0 > - Looked which minor/major to allow > r...@ksxxx:~# ls -l /dev/mapper/ > total 0 > crw-rw 1 root root 10, 60 2010-02-13 14:22 control > brw-rw 1 root disk 252, 3 2010-03-02 12:51 crypt_newzer > brw-rw 1 root disk 252, 3 2010-03-02 12:51 > crypt_newzer_unformatted > brw-rw 1 root disk 252, 1 2010-02-13 14:22 vg0-backup_restore > brw-rw 1 root disk 252, 2 2010-03-02 12:22 vg0-cr_newzer > brw-rw 1 root disk 252, 0 2010-02-13 14:22 vg0-lxc > - I have allowed it (i have deduced it from exemples) > r...@ksxxx:~# cat /var/lib/lxc/newzer.ovh2.p.zitta.fr/config | > grep 252:3 > lxc.cgroup.devices.allow = b 252:3 rwm > - And plouf, an error :( > r...@ksxxx:~# lxc-start -n newzer.ovh2.p.zitta.fr > lxc-start: Operation not permitted - failed to mount > '/dev/mapper/crypt_newzer' on > '/var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs/home' > lxc-start: failed to setup the mounts for 'newzer.ovh2.p.zitta.fr' > lxc-start: failed to setup the container > > So I'm wondering if it is possible, if i have made a mistake... Voila > > Any idea? > Thanks > You want to use an image to mount the rootfs, right ? This is partly implemented but disabled in the code right now. Do you have an example of the image I can download somewhere in the net, so I can finish this part and test ? In the meantime, you can mount the image somewhere in a directory and use it as the rootfs - I know this is not what you want to do but anyway ... :) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] summary of the latest discussions and pending patchset
Ciprian Dorin, Craciun wrote: > On Sun, Jan 10, 2010 at 11:36 PM, Daniel Lezcano > wrote: > >> Hi all, >> >> A little summary of what was talked about and what is pending: >> >> [... snip ...] >> >> * Statically link the executable >> >> Ciprian Dorin sent a patchset in order to generate a static library and >> link against it. >> That was a wish of Michael T Johnson of Foresight Linux. >> I will take the patchset. >> >> [... snip ...] >> > > > Hy Daniel! > > A few months ago I've sent a patch that allows the user to > configure and build a static version of all our binaries. We've > exchanged a few emails about the subject (the date was after the quote > above). But then the subject was dropped. > > Could I reiterate the proposal? Is there something wrong with my > approach? Should I do it in some other (better) way? > > If interested my repository is at the following URL (the diff with > the current master is at the end of the email): > git://gitorious.org/~ciprian.craciun/lxc/ciprian-craciun-patches.git > > Thanks, > Ciprian. > > P.S.: I've also created a "mainline" mirror of LXC repository on > Gitorious: > http://gitorious.org/lxc/mainline > > If someone wants ownership to this repository please tell me. > (I've created it because there will be users (like myself) that would > like to "fork" it from there, and thus we could see which are > potential developers to LXC.) > > My `static-build` diff to current master: > Yep, the first problem with the log category was solved by Cedric but then I forgot to take your patch. Will look at it thanks. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC container fails to start by complaining that it is unable to unmount the old pivot-root
Ciprian Dorin, Craciun wrote: > On Tue, Feb 2, 2010 at 8:06 PM, Daniel Lezcano wrote: > >> Andrian Nord wrote: >> >>> On Mon, Feb 01, 2010 at 01:54:15PM -0500, Michael H. Warfield wrote: >>> >>> >>>> On Mon, 2010-02-01 at 19:46 +0200, Ciprian Dorin, Craciun wrote: >>>> >>>> >>>>> Hello all! >>>>> >>>>> I have a quite strange problem: the container fails to start and >>>>> complains about being unable to unmount the old pivot root. >>>>> (What is strange is that I remember that one moth ago the same >>>>> setup worked (lxc binaries and config file, but maybe 2.6.31 kernel). >>>>> Now neither the old binaries or the latest ones from Git don't work.) >>>>> >>>>> >>> Taken from http://blog.flameeyes.eu/2010/01/31/lxc-s-unpolished-code >>> "So what about the 0.6.5 problem? Well the problem came to be because >>> 0.6.5 actually implements a nice feature (contributed by a non-core >>> developer it seems): root pivoting. The idea is to drop access to the >>> old root, so that the guest cannot in any way access the host’s >>> filesystem unless given access to. It’s a very good idea, but there are >>> two problems with it: it doesn’t really do it systematically, but rather >>> with a “try and hope” approach, and it failed under certain conditions, >>> saying that the original root is still busy (note here, since this >>> happens within the cgroup’s mount namespace, it doesn’t matter to the >>> rest of the system). >>> >>> At the end, last night I was able to identify the problem: I had this >>> line in the fstab file used by lxc itself: >>> none /tmp tmpfs size=200m 0 0 >>> >>> What’s wrong with it? The mountpoint. The fstab (and lxc.mount commands) >>> are used without previous validation or handling, so this is not >>> mounting the /tmp for the guest, but the /tmp for the host, within the >>> guest’s mount namespace. The result is that /tmp gets mounted twice >>> (once inherited by the base mount namespace, once within the guest’s >>> namespace, but it’s only unmounted once (as the unmount list keeps each >>> mount point exactly once). This is quite an obvious error on my part, I >>> should have used /media/chroots/tinderbox/tmp as mountpoint, but LXC >>> being unable to catch the mistake in mountpoint (at least warning about >>> it) is a definite problem." >>> >>> That's Gentoo maintainer for lxc ebuilds. May you check if this is >>> source of the problem? >>> >>> >> Ha ! Let's check ! :) >> > > > Hy there! > > I just want to inform you that the latest master > 7d9fb3e9d2b9722040f37f0e01e29d071f4c6fe8 (from 26th February) solves > the problem of unmounting. Now everything works perfectly. > > Sorry for being late with the feedback! > > Thanks, > Ciprian. > Thanks Ciprian ! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Building man pages fails
Ciprian Dorin, Craciun wrote: > On Tue, Mar 2, 2010 at 7:11 PM, Ciprian Dorin, Craciun > wrote: > >>Hy there! >> >>I wanted to ask this for some time now, but only today I've made >> some time... So... >> >>My context: >>* ArchLinux (latest); >>* db2x_xsltproc (part of docbook2X 0.8.8) $Revision: 1.5 $ $Date: >> 2004/08/18 14:21:52 $ >>* /usr/bin/docbook2man (part of docbook2X 0.8.8) $Revision: 1.12 $ >> $Date: 2006/04/14 17:29:04 $ >>* I can't find anywhere the `-w` option in `man docbook2man` >> >>When building the man pages I get the following errors: >> >> ./autogen.sh >> ./configure >> cd ./doc >> make lxc-create.1 >> >> docbook2man -w lxc-create.sgml >> /usr//bin/db2x_xsltproc: Unknown option: w >> Try "/usr//bin/db2x_xsltproc --help" for more information. >> Unable to recognise encoding of this document at >> /usr/share/perl5/vendor_perl/XML/SAX/PurePerl/EncodingDetect.pm line >> 100. >> Document requires an element [Ln: 1, Col: 0] >> make: *** [lxc-create.1] Error 9 >> >> >>First fix-up: eliminate the `-w` from the Makefile: >> >> make lxc-create.1 >> >> cd .. && /bin/sh /home/ciprian/desktop/workbench/lxc/config/missing >> --run automake-1.11 --gnu doc/Makefile >> cd .. && /bin/sh ./config.status doc/Makefile >> config.status: creating doc/Makefile >> docbook2man lxc-create.sgml >> lxc-create.sgml:26: parser error : SystemLiteral " or ' expected >> > ^ >> lxc-create.sgml:26: parser error : SYSTEM or PUBLIC, the URI is missing >> > ^ >> lxc-create.sgml:137: parser error : Entity 'seealso' not defined >> &seealso; >> ^ >> unable to parse lxc-create.sgml >> Unable to recognise encoding of this document at >> /usr/share/perl5/vendor_perl/XML/SAX/PurePerl/EncodingDetect.pm line >> 100. >> Document requires an element [Ln: 1, Col: 0] >> make: *** [lxc-create.1] Error 9 >> >> >>Second fix-up: seems that the problem is fixable by replacing the >> following line: >>>with: >>> "/dev/null" [ >> >>(I've reached this solution by putting first "", then it >> complained it can not open the file '', thus I've put there >> /dev/null). >> >>Now everything seems Ok. >> >>Any ideas what is wrong here? My packages? Anything with the doocbook? >> >>Thanks, >>Ciprian. >> > > > Ups... Didn't knew about the bug tracker... :) > Next time I'll add the bug my self. (Thanks Daniel!) > No problem, it is not obvious there is a bug tracker opened for this project. I hope one day I have the time to make some good documentation for the project on the sourceforge website :) Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] mounting a crypted volume in a container
l...@zitta.fr wrote: > Le 02/03/2010 18:13, Daniel Lezcano a écrit : > >> l...@zitta.fr wrote: >> >>> hi, >>> >>> I'm trying to provide a crypted volume to a container : >>> - So i have added it to the container's fstab : >>> r...@ksxxx:~# cat /var/lib/lxc/newzer.ovh2.p.zitta.fr/fstab >>> /lxc/root/newzer.ovh2.p.zitta.fr >>> /var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs none rbind 0 0 >>> /dev/mapper/crypt_newzer >>> /var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs/home ext4 defaults 0 0 >>> - Looked which minor/major to allow >>> r...@ksxxx:~# ls -l /dev/mapper/ >>> total 0 >>> crw-rw 1 root root 10, 60 2010-02-13 14:22 control >>> brw-rw 1 root disk 252, 3 2010-03-02 12:51 crypt_newzer >>> brw-rw 1 root disk 252, 3 2010-03-02 12:51 >>> crypt_newzer_unformatted >>> brw-rw 1 root disk 252, 1 2010-02-13 14:22 >>> vg0-backup_restore >>> brw-rw 1 root disk 252, 2 2010-03-02 12:22 vg0-cr_newzer >>> brw-rw 1 root disk 252, 0 2010-02-13 14:22 vg0-lxc >>> - I have allowed it (i have deduced it from exemples) >>> r...@ksxxx:~# cat /var/lib/lxc/newzer.ovh2.p.zitta.fr/config | >>> grep 252:3 >>> lxc.cgroup.devices.allow = b 252:3 rwm >>> - And plouf, an error :( >>> r...@ksxxx:~# lxc-start -n newzer.ovh2.p.zitta.fr >>> lxc-start: Operation not permitted - failed to mount >>> '/dev/mapper/crypt_newzer' on >>> '/var/lib/lxc/newzer.ovh2.p.zitta.fr/rootfs/home' >>> lxc-start: failed to setup the mounts for >>> 'newzer.ovh2.p.zitta.fr' >>> lxc-start: failed to setup the container >>> >>> So I'm wondering if it is possible, if i have made a mistake... Voila >>> >>> Any idea? >>> Thanks >>> >>> >> You want to use an image to mount the rootfs, right ? >> This is partly implemented but disabled in the code right now. >> Do you have an example of the image I can download somewhere in the >> net, so I can finish this part and test ? >> >> In the meantime, you can mount the image somewhere in a directory and >> use it as the rootfs - I know this is not what you want to do but >> anyway ... :) >> >> >> >> > I have done a what you need, URL will follow in a private mail. > > For my problem, it is a crypted datadir for a backup server, not a rootfs. > I wanted to use /var/lib/lxc/container/fstab to have the block device > mounted at lxc startup whitout use any wrapper around lxc-start. > > For my education, is there any differences between these two solutions : > - using /var/lib/lxc/container/fstab > - mknod in the container + use his /etc/fstab > Do you mean rootfs in the container ? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Ubuntu Karmic container
Elias Olivares wrote:
> Hi !
>
> Here a new bug installing ubuntu karmic into a container :
>
> I've installed karmic with debootstrap and when i try to run the container ,
> it don't and this error message appears on the screen :
>
> mountall:/dev/ppp: Operation not permitted
> mountall:/dev/net/tun: Operation not permitted
> mountall:/dev/loop0: Operation not permitted
>
> But the container seems to run :
>
> host# lxc-info -n karmic
> 'karmictest.1g6.biz' is RUNNING
>
> The command lxc-ls seems to be broken : (it show 2 times the container)
>
> vms:/mnt/vz# lxc-ls
> karmictest
> karmictest
>
Yes, that was reported one time, it's displayed twice because it is
created and because it is running.
I guess there is some polishing to do with this command.
> My container configuration file :
>
> lxc.utsname = karmictest
> lxc.tty = 4
> lxc.pts = 1024
> lxc.network.type = veth
> lxc.network.flags = up
> lxc.network.link = br0
> lxc.network.name = eth0
> lxc.network.mtu = 1500
> #lxc.mount =
> lxc.rootfs = /mnt/vz/karmictest
>
Can you try by disabling the cgroup.devices section below and try to
start the container ?
If you can start it, it is probable you have to allow more devices to be
created within the container, (eg : b 7 0 for the loop0)
> lxc.cgroup.devices.deny = a
> # /dev/null and zero
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> # consoles
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> # /dev/{,u}random
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> # rtc
> lxc.cgroup.devices.allow = c 254:0 rwm
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] bugs with LXC container : mount and rmmod command
Elias Olivares wrote: > Hi ! > > I've tried to reproduce this bug on 0.6.5 lxc release and the same bug > appears when i run the umount command or rmmod command. > > To reproduce the bug : > > Host name : debian > Guest container name : container > > You MUST create a dedicated partition to share your containers (an other > partition than " / ") > > debian:# df > > /dev/hda1 7850996 2058732 5393452 28% / > tmpfs 253768 0 253768 0% /lib/init/rw > udev 10240 108 10132 2% /dev > tmpfs 253768 0 253768 0% /dev/shm > /dev/hdb1 4127076 552552 3364880 15% /mnt/vmr1 > > Then enter into the container (lxc-console -n container) and stop cron, > syslog, bind 9,ssh processes. > > container:~# ps aux > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 1 0.0 0.1 1984 692 ? Ss 11:10 0:00 init [2] > root 387 0.0 0.4 5884 2272 console Ss 11:10 0:00 /bin/login -- > root 388 0.0 0.1 1992 572 tty1 Ss+ 11:10 0:00 /sbin/getty 38400 tty1 > root 389 0.0 0.1 1992 568 tty2 Ss+ 11:10 0:00 /sbin/getty 38400 tty2 > root 390 0.0 0.1 1992 568 tty3 Ss+ 11:10 0:00 /sbin/getty 38400 tty3 > root 392 0.0 0.5 4132 2680 console S 11:11 0:00 -bash > root 584 0.0 0.1 2644 956 console R+ 11:43 0:00 ps aux > > Then use the mount command : > > container:~# mount -o remount,ro / > > Return to the Host and try to create a file in /mnt/vmr1/ . The folder is set > in "read only". For this one, I don't know if it's a kernel bug or a lxc bug. To be investigated ... > The second bug : > > Install ntfs module in the host : (exemple with ntfs module) > > debian:# modprobe ntfs > > Enter into the container and delete ntfs module > > container:~# rmmod ntfs > > Return to the host : the module has been removed > > Does anyone have solved this problem ? > > I think it is a major security problem. You have to drop the sys_module capability for the container. That is done by adding in the container configuration file: lxc.cap.drop = sys_module If you want to drop more capabilities, you can refer to the capabilities (7) man page. If you want to drop for example CAP_SYS_TIME, add lxc.cap.drop = sys_time Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [Fwd: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.]
Hi all,
just to let you know there is a discussion and a patchset to enter a
container.
I will prototype the two commands lxc-enter and lxc-exec to make use of
this new kernel functionality. I will be happy if someone is willing to
play with these new commands when they are finished.
I hope the patchset will be available for 2.6.35 :)
Original Message
Subject:Re: [RFC][PATCH] ns: Syscalls for better namespace sharing
control.
Date: Mon, 08 Mar 2010 00:32:49 -0800
From: ebied...@xmission.com (Eric W. Biederman)
To: Daniel Lezcano
CC: Pavel Emelyanov , Sukadev Bhattiprolu
, Serge Hallyn , Linux
Netdev List ,
contain...@lists.linux-foundation.org, Netfilter Development Mailinglist
, Ben Greear
References: <4b88e431.6040...@parallels.com>
<4b894564.7080...@parallels.com>
<4b89727c.9040...@parallels.com>
<4b8ae8c1.1030...@free.fr>
<4b8d28cf.8060...@parallels.com> <20100302211942.ga17...@us.ibm.com>
<20100303000743.ga13...@us.ibm.com>
<4b8e9370.3050...@parallels.com>
<4b9158f5.5040...@parallels.com>
<4b926b1b.5070...@free.fr>
<4b92c886.9020...@free.fr>
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>> I am going to explore a bit more. Given that nsfd is using the same
>> permission checks as a proc file, I think I can just make it a proc
>> file. Something like "/proc//ns/net". With a little luck that
>> won't suck too badly.
>>
> Ah ! yes. Good idea.
It is a hair more code to use proc files but nothing worth counting.
Probably the biggest thing I am aware of right now in my development
tree is in getting uids to pass properly between unix domain sockets
I would up writing this cred_to_ucred function.
Serge can you take a look and check my logic, and do you have
any idea of where we should place something like pid_vnr but
for the uid namespace?
void cred_to_ucred(struct pid *pid, const struct cred *cred,
struct ucred *ucred)
{
ucred->pid = pid_vnr(pid);
ucred->uid = ucred->gid = -1;
if (cred) {
struct user_namespace *cred_ns = cred->user->user_ns;
struct user_namespace *current_ns = current_user_ns();
struct user_namespace *tmp;
if (likely(cred_ns == current_ns)) {
ucred->uid = cred->euid;
ucred->gid = cred->egid;
} else {
/* Is cred in a child user namespace */
tmp = cred_ns;
do {
tmp = tmp->creator->user_ns;
if (tmp == current_ns) {
ucred->uid = tmp->creator->uid;
ucred->gid = overflowgid;
return;
}
} while (tmp != &init_user_ns);
/* Is cred the creator of my user namespace,
* or the creator of one of it's parents?
*/
for( tmp = current_ns; tmp != &init_user_ns;
tmp = tmp->creator->user_ns) {
if (cred->user == tmp->creator) {
ucred->uid = 0;
ucred->gid = 0;
return;
}
}
/* No user namespace relationship so no mapping */
ucred->uid = overflowuid;
ucred->gid = overflowgid;
}
}
}
Eric
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Fwd: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.]
Ciprian Dorin, Craciun wrote: > Please let me know when such patchset / afferent tools are > available. (I hope that the patchset is also applicable to prior > kernel verions (.33, .34)...) > Mmh, would it makes sense to have an out-of-tree lxc kernel grouping all the patches around related to the containers ? like sysfs per namespace, udev event, entering a container ... At least the ones having a very good chance to be merged upstream ? > Ciprian. > > P.S.: For those interested I'm playing with LXC to isolate > different applications, and my intent is that my working machine is > going to be a combination of Gentoo (or Debian?) (for boot, > networking, disk, and services), ArchLinux (for desktop applicaions > like Firefox and OpenOffice), and custom built applications (here LXC > allows me to separate the roots so that the package managers are not > going to interfere one with another). I also want that all my services > (dnscache, polipo proxy, etc.) to be contained in restricted > containers. > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Fwd: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.]
Ciprian Dorin, Craciun wrote: > On Mon, Mar 8, 2010 at 10:50 PM, Daniel Lezcano > wrote: > >> Ciprian Dorin, Craciun wrote: >> >>>Please let me know when such patchset / afferent tools are >>> available. (I hope that the patchset is also applicable to prior >>> kernel verions (.33, .34)...) >>> >>> >> Mmh, would it makes sense to have an out-of-tree lxc kernel grouping all the >> patches around related to the containers ? >> like sysfs per namespace, udev event, entering a container ... >> At least the ones having a very good chance to be merged upstream ? >> > > For me (and others wanting to try the latest and greatest features > about the containers) it would be a very good idea to either provide a > clean patch for the proposed features. And even maybe someone could > provide a branch of the latest stable kernel with these patches ontop. > (I could maintain such a branch, as I frequently compile the stable > kernel myself from Linus's tree.) > > So if you can provide these patches I would like to thank you in advance. > :) > Ciprian. > Ok. Will look at gathering such patches. Is the 2.6.33 a good target ? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] child setpgid [...] : No such process
l...@zitta.fr wrote: > Le 11/03/2010 19:47, Daniel Lezcano a écrit : > >> l...@zitta.fr wrote: >> >>> I created a new container (karmic), then I type any command there is >>> curious message, but it works: >>> >>> >> Do you mean you created a system container with karmic inside ? >> > Yes, I'm testing a new version of my provisioning scripts. > >> Can you give the kernel version, the lxc version, the container >> configuration and the command used to spawn the container ? >> > > config as attachment. > > black provisioning # uname -a > Linux black 2.6.31-zen11-lxc-bt #1 ZEN SMP PREEMPT Tue Feb 23 09:13:02 > CET 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz GenuineIntel > GNU/Linux > > black provisioning # eix -I lxc | grep Installed > Installed versions: 0.6.4-r2(22:25:37 04/01/2010)(doc -examples) > > Container started with : lxc-start -d -n mycontainer > > I access to it via ssh. > > Just a question, config file is used at once at create? > >>> r...@mycontainer:~# ls / >>> -bash: child setpgid (28212 to 28212): No such process >>> bin boot dev etc home lib lib64 media mnt opt proc root >>> sbin selinux srv sys tmp usr var >>> When you are in the container, can you give the ouput of: echo $$ ps axjf -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] child setpgid [...] : No such process
l...@zitta.fr wrote: > Le 12/03/2010 13:51, Daniel Lezcano a écrit : > >> l...@zitta.fr wrote: >> >>> Le 11/03/2010 19:47, Daniel Lezcano a écrit : >>> >>> >>>> l...@zitta.fr wrote: >>>> >>>> >>>>> I created a new container (karmic), then I type any command there is >>>>> curious message, but it works: >>>>> >>>>> >>>> Do you mean you created a system container with karmic inside ? >>>> >>>> >>> Yes, I'm testing a new version of my provisioning scripts. >>> >>> >>>> Can you give the kernel version, the lxc version, the container >>>> configuration and the command used to spawn the container ? >>>> >>>> >>> config as attachment. >>> >>> black provisioning # uname -a >>> Linux black 2.6.31-zen11-lxc-bt #1 ZEN SMP PREEMPT Tue Feb 23 09:13:02 >>> CET 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz GenuineIntel >>> GNU/Linux >>> >>> black provisioning # eix -I lxc | grep Installed >>> Installed versions: 0.6.4-r2(22:25:37 04/01/2010)(doc -examples) >>> >>> Container started with : lxc-start -d -n mycontainer >>> >>> I access to it via ssh. >>> >>> Just a question, config file is used at once at create? >>> >>> >>>>> r...@mycontainer:~# ls / >>>>> -bash: child setpgid (28212 to 28212): No such process >>>>> bin boot dev etc home lib lib64 media mnt opt proc root >>>>> sbin selinux srv sys tmp usr var >>>>> >>>>> >> When you are in the container, can you give the ouput of: >> >> echo $$ >> ps axjf >> >> >> >> > yes, I can : > > r...@mycontainer:~# ls > -bash: child setpgid (1905 to 1905): No such process > r...@mycontainer:~# echo $$ > 74 > r...@mycontainer:~# ps axjf > -bash: child setpgid (1907 to 1907): No such process > PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND > 0 1 1 1 ? -1 Ss 0 0:00 /sbin/init > 1131010 ? -1 Sl 101 0:00 rsyslogd -c4 > 1545454 ? -1 Ss 0 0:00 /usr/sbin/sshd > 1686868 tty181 Ss 0 0:00 /bin/login > -- >68747468 tty181 S0 0:00 \_ -bash >74818168 tty181 R+ 0 0:00 \_ ps axjf > Very weird ... Another one :) strace -f -eclone,setpgid bash and then /bin/true (or whatever). -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] child setpgid [...] : No such process
l...@zitta.fr wrote: > Le 12/03/2010 14:15, Daniel Lezcano a écrit : > >> l...@zitta.fr wrote: >> >>> Le 12/03/2010 13:51, Daniel Lezcano a écrit : >>> >>> >>>> l...@zitta.fr wrote: >>>> >>>> >>>>> Le 11/03/2010 19:47, Daniel Lezcano a écrit : >>>>> >>>>> >>>>> >>>>>> l...@zitta.fr wrote: >>>>>> >>>>>> >>>>>>> I created a new container (karmic), then I type any command there is >>>>>>> curious message, but it works: >>>>>>> >>>>>>> >>>>>> Do you mean you created a system container with karmic inside ? >>>>>> >>>>>> >>>>> Yes, I'm testing a new version of my provisioning scripts. >>>>> >>>>> >>>>> >>>>>> Can you give the kernel version, the lxc version, the container >>>>>> configuration and the command used to spawn the container ? >>>>>> >>>>>> >>>>> config as attachment. >>>>> >>>>> black provisioning # uname -a >>>>> Linux black 2.6.31-zen11-lxc-bt #1 ZEN SMP PREEMPT Tue Feb 23 09:13:02 >>>>> CET 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz >>>>> GenuineIntel >>>>> GNU/Linux >>>>> >>>>> black provisioning # eix -I lxc | grep Installed >>>>> Installed versions: 0.6.4-r2(22:25:37 04/01/2010)(doc -examples) >>>>> >>>>> Container started with : lxc-start -d -n mycontainer >>>>> >>>>> I access to it via ssh. >>>>> >>>>> Just a question, config file is used at once at create? >>>>> >>>>> >>>>> >>>>>>> r...@mycontainer:~# ls / >>>>>>> -bash: child setpgid (28212 to 28212): No such process >>>>>>> bin boot dev etc home lib lib64 media mnt opt proc root >>>>>>> sbin selinux srv sys tmp usr var >>>>>>> >>>>>>> >>>> When you are in the container, can you give the ouput of: >>>> >>>> echo $$ >>>> ps axjf >>>> >>>> >>>> >>>> >>>> >>> yes, I can : >>> >>> r...@mycontainer:~# ls >>> -bash: child setpgid (1905 to 1905): No such process >>> r...@mycontainer:~# echo $$ >>> 74 >>> r...@mycontainer:~# ps axjf >>> -bash: child setpgid (1907 to 1907): No such process >>> PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND >>> 0 1 1 1 ? -1 Ss 0 0:00 /sbin/init >>> 1131010 ? -1 Sl 101 0:00 rsyslogd >>> -c4 >>> 1545454 ? -1 Ss 0 0:00 >>> /usr/sbin/sshd >>> 1686868 tty181 Ss 0 0:00 /bin/login >>> -- 68747468 tty181 S0 >>> 0:00 \_ -bash >>>74818168 tty181 R+ 0 0:00 \_ >>> ps axjf >>> >>> >> Very weird ... >> >> Another one :) >> >> strace -f -eclone,setpgid bash >> and then /bin/true (or whatever). >> >> >> >> > At same time, I was upgrading my kernel from 2.6.31 to 2.6.33. > And it works now. > I have done a rollback to reproduce. Clearly, my old kernel is the issue. > Yep, I am suspecting a bug in the 2.6.31 kernel. Do you mind to give the ouput of the strace for each kernel ? Do you have a patched kernel ? I used the 2.6.31 but I don't recall falling onto this problem ... > After some searches, it seems that my 2.6.31 kernel loosed 2 config > items from my previous config : > CONFIG_CGROUP_CPUACCT > CONFIG_CGROUP_SCHED > > do you think this is the problem ? > At the fist glance, I would say no, I don't think this is in the "clone" / "copy_proces" kernel code path. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Fixed (hacked) LXC to apply mount options for bind mounts
Ciprian Dorin, Craciun wrote:
> On Mon, Mar 8, 2010 at 11:35 PM, Ciprian Dorin, Craciun
> wrote:
>
>>Hello all!
>>
>>This bug stalked me for a while, but only now it bit me quite
>> badly... (Lost about an hour of work...)
>>
>>So the culprit: inside the fstab file for the `lxc.mount` option I
>> can use options like `ro` together with `bind`. Unfortunately the
>> kernel just laughs in my face and ignores any options I've put in
>> there... :) But not any more: I've updated `./src/lxc/conf.c`
>> (`mount_file_entries` function) so that when it encounters a `bind`
>> option it executes it twice (one without any extra options, and a
>> second time with the remount flag set.)
>>
>>I've marginally (as in my particular case) tested it and it works.
>>
>>Any other ideas on how to solve this? Any comments?
>>Ciprian.
>>
>>P.S.: One question though (both in the patched and unpatched
>> versions): it seems that if I put two lines inside the fstab, once
>> with only `bind` options, and a second one with `remount,ro` option it
>> doesn't work and I receive the error `No such device - failed to
>> mount`. But this is equivalent with what my patched version is doing
>> (which works)... Strange...
>>
>>
>> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
>> index 26ddd03..f7c5816 100644
>> --- a/src/lxc/conf.c
>> +++ b/src/lxc/conf.c
>> @@ -801,11 +801,20 @@ static int mount_file_entries(FILE *file)
>>}
>>
>>if (mount(mntent->mnt_fsname, mntent->mnt_dir,
>> - mntent->mnt_type, mntflags, mntdata)) {
>> + mntent->mnt_type, mntflags & ~MS_REMOUNT,
>> mntdata)) {
>>SYSERROR("failed to mount '%s' on '%s'",
>> mntent->mnt_fsname, mntent->mnt_dir);
>>goto out;
>>}
>> + if ((mntflags & MS_REMOUNT == MS_REMOUNT) || (mntflags
>> & MS_BIND == MS_BIND)) {
>> + DEBUG ("remounting %s on %s to respect bind or
>> remount options", mntent->mnt_fsname, mntent->mnt_dir);
>> + if (mount(mntent->mnt_fsname, mntent->mnt_dir,
>> + mntent->mnt_type, mntflags |
>> MS_REMOUNT, mntdata)) {
>> + SYSERROR("failed to mount '%s' on '%s'",
>> +mntent->mnt_fsname,
>> mntent->mnt_dir);
>> + goto out;
>> + }
>> + }
>>
>>DEBUG("mounted %s on %s, type %s", mntent->mnt_fsname,
>> mntent->mnt_dir, mntent->mnt_type);
>>
>
>
> Forgot to montion that my changeset is also available on Gitorious:
> clone-URL
> git://gitorious.org/~ciprian.craciun/lxc/ciprian-craciun-patches.git
> branch: patches/bind-remount
> Or view on-line:
>
> http://gitorious.org/~ciprian.craciun/lxc/ciprian-craciun-patches/commits/patches/bind-remount
>
Thanks Ciprian for the report.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] a container can remount ro the host's mount point
Michael H. Warfield wrote: > On Mon, 2010-03-15 at 15:39 +0100, l...@zitta.fr wrote: > >> Le 15/03/2010 15:05, Michael H. Warfield a écrit : >> >>> On Sun, 2010-03-14 at 08:33 +0100, l...@zitta.fr wrote: >>> >>> Hi, When I create a full os container (for example a debian), I have to remove init script that remount / read only on halt example : umountfs for lenny If I don't do this, the container remounts readonly the mount point where rootfs are when it stops. Why a container is able to do this? If you store multiples containers on the same mount point, it could be very problematic. >>> Ah HA! So THAT'S the root cause of THAT problem. Several of us have >>> noticed that effect. Yeah, major PITA. Also explains just why I no >>> longer see it. Because of a practice I started using in setting up my >>> containers... >>> >>> As it so happens, because all of my containers are OpenVZ compatibility >>> containers, I use a bind mount in the fstab for the root fs. OpenVZ has >>> this concept of a "private" and a "rootfs" to aid in setting disk quotas >>> in the container and I'm hoping to also eventually use that with union >>> mounts / unionfs to do a linux-vservers style unify. But... That also >>> prevents this problem because the container's rootfs is NOT a real fs in >>> the host, it's the bind mount and that insulates the hosts fs and mount >>> points from any actions in the container. >>> >>> Example from one of my containers is like this: >>> >>> Config: >>> >>> == >>> lxc.rootfs = /srv/lxc/rootfs >>> lxc.mount = /srv/lxc/config/1004.fstab >>> = >>> >>> fstab: >>> >>> == >>> /srv/lxc/private/1004 /srv/lxc/rootfsnone bind 0 0 >>> >>> /export /srv/lxc/rootfs/exportnone bind 0 0 >>> /home/shared /srv/lxc/rootfs/srv/sharednone bind 0 0 >>> == >>> >>> Would be really NICE if that bind could be something like a fuse with >>> unionfs or, eventually, a union mount once those are mature and stable >>> in the kernel, but we're not there yet. >>> >>> Now, you won't actually see anything in /srv/lxc/rootfs because it's >>> private to the container and it's just a dummy mount point that can be >>> used by all of your containers. The only thing that varies between my >>> containers then is the location of the fstab (and the network stuff, >>> obviously). The container can screw up its mounts all it want's their >>> ALL isolated and private to the container, including the rootfs. >>> >>> >>> Regards, >>> >>> Guillaume ZITTA >>> Regards, >>> Mike >>> >>> >> Thanks. >> I noticed that practice whas used by lxc-create in version 0.6.3 >> > > No, not exactly, and it wasn't being done by lxc-create. lxc-create was > merely creating the directory, it was not doing the bind mount and could > not do the bind mount. The actual mount was being done by lxc-start at > run time when starting that container. The code in lxc-create was > removed because the behavior of lxc-start was changed to no longer > require that directory. > > >> with lxc-0.6.3, lxc-create is a binary and it does this for you and >> other things in /var/lib/lxc >> with lxc-0.6.5, lxc-create is a shell script and it does less things >> than the binary one >> > > Close but not quite. > > >> Is this a voluntary regression? >> > > It was a change (and Daniel may chime in here an correct me at any > moment) coupled with the introduction of using pivot root to actually > improve the isolation of the containers from the host and prevent the > containers from breaking out of their chrooted jails. That was a > security fix. He did drop that additional bind mount at that time and > yes that did provide the additional functional isolation in this one > peculiar way that protected the host from random acts of terrorism by > the container on its rootfs. > An unanticipated side effect. > Right, but lxc-start creates a temporary directory in /tmp called lxc-XXX Then the rootfs is bind mounted to /tmp/lxc-XX and so pivot_root is done in this directory. What is the difference with what was doing the 0.6.3 version with a previous bind mount in /var/lib/lxc//rootfs ? >> If not I propose myself to update lxc-create script to propose the same >> kind of functionality than the C version. >> > > No. Do not do that. It did not work the way you're thinking it did and > that will not work. It would create a situation where you would have to > rerun lxc-create after reboot or restarting because you will have lost > the bind mounts. This never was done in lxc-create, only the creation > of the directory. The mounting is done in lxc-start and must be done in > lxc-start. Don't do this. Personally, I like the method of adding the > bind mount explicitly to the fstab and plan to continue that way.
Re: [lxc-devel] patch for lxc-checkconfig
l...@zitta.fr wrote: > Hi, > > 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 > > --- /usr/sbin/lxc-checkconfig2010-03-12 14:35:38.0 +0100 > +++ /usr/local/bin/lxc-checkconfig2010-03-14 07:46:53.940193560 +0100 > You patched the wrong file but, as the patch is trivial, I ported the modifications to the right file, src/lxc/lxc-checkconfig.in. In the future, patch the source code instead the installed scripts ;) Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 9ea8066aa67b808f71f46e346bd7a215e2a355f3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lxc".
The branch, master has been updated
via 9ea8066aa67b808f71f46e346bd7a215e2a355f3 (commit)
via 341553f769afd3e73219f5fbf5cd79c054e2333f (commit)
via adc1e6c25d39840aa76d665361d3b6dd7373acd9 (commit)
via 0a3ec350143c95031e5d96fe4a033cfb0772d27f (commit)
via 81c75799cc753a51afb6e17979b2923212986ad3 (commit)
via 28a4b0e55c659428bc8f495fde2e774fbd0fb03c (commit)
via 80090207defda9adfc922555b359b11acdad1401 (commit)
from 7d9fb3e9d2b9722040f37f0e01e29d071f4c6fe8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 9ea8066aa67b808f71f46e346bd7a215e2a355f3
Author: Daniel Lezcano
Date: Mon Mar 22 11:08:34 2010 +0100
fix lxc-setcap script for lxc-attach
Fix type and missing capability.
Signed-off-by: Daniel Lezcano
commit 341553f769afd3e73219f5fbf5cd79c054e2333f
Author: Michel Normand
Date: Mon Mar 22 11:08:34 2010 +0100
do not use logfile in lxc_init (V2)
The log file in lxc-init is quite useless as the code is trivial.
Signed-off-by: Michel Normand
Signed-off-by: Cedric Le Goater
Signed-off-by: Daniel Lezcano
commit adc1e6c25d39840aa76d665361d3b6dd7373acd9
Author: Michel Normand
Date: Mon Mar 22 11:08:34 2010 +0100
typo in error message
Wrong variable.
Signed-off-by: Michel Normand
Signed-off-by: Daniel Lezcano
commit 0a3ec350143c95031e5d96fe4a033cfb0772d27f
Author: Daniel Lezcano
Date: Mon Mar 22 11:08:34 2010 +0100
fix lxc-attach returned error
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
Signed-off-by: Michel Normand
commit 81c75799cc753a51afb6e17979b2923212986ad3
Author: Daniel Lezcano
Date: Mon Mar 22 11:08:34 2010 +0100
lxc: enter / exec a command inside a container V2
This patch allows to execute a command or enter inside the container:
* lxc-attach -n [command]
If the , the lxc-attach will retrieve your uid
and get your shell name and exec it in the container.
Signed-off-by: Daniel Lezcano
commit 28a4b0e55c659428bc8f495fde2e774fbd0fb03c
Author: Daniel Lezcano
Date: Mon Mar 22 11:08:34 2010 +0100
open the console later
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
commit 80090207defda9adfc922555b359b11acdad1401
Author: Cedric Le Goater
Date: Mon Mar 22 11:08:34 2010 +0100
lxc: forbid open fds upon startup
This patch modifies the startup of a container to forbid opened
fds, unless these are stdios.
Signed-off-by: Cedric Le Goater
---
Summary of changes:
src/lxc/Makefile.am |2 +
src/lxc/arguments.c | 14 -
src/lxc/commands.c| 13 +++--
src/lxc/commands.h|2 +
src/lxc/conf.c|3 +-
src/lxc/conf.h|1 +
src/lxc/confile.c | 18 ++-
src/lxc/console.c |9 +++
src/lxc/lxc-setcap.in |3 +-
src/lxc/lxc_attach.c | 135 +
src/lxc/lxc_init.c| 21 +---
src/lxc/lxc_start.c |6 +-
src/lxc/namespace.c | 62 ++-
src/lxc/namespace.h |1 +
src/lxc/start.c | 90 ++--
src/lxc/start.h |1 +
src/lxc/utils.c | 126 -
src/lxc/utils.h |2 -
18 files changed, 331 insertions(+), 178 deletions(-)
create mode 100644 src/lxc/lxc_attach.c
hooks/post-receive
--
lxc
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] entering a container
Hi all, I added the patchset: http://lxc.sourceforge.net/patches/2.6.33/2.6.33.1/2.6.33.1-lxc1/patches.tar.gz This first drop contains the patchset to enter a container. There is one bug when you kill the container while there is a command attached to the container. I noticed another bug with macvlan and this kernel (not related to lxc but it needs to be investigated). The userspace code was commited. I have more enhancement for the command in my tree, but I will wait a bit before committing them. The new command is "lxc-attach". The syntax is: lxc-attach -n [command] If 'command' is omitted, a shell is launched in the container. Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 9b8e796c37e4fa9291de31f94dbc9e06216b58ff
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 9b8e796c37e4fa9291de31f94dbc9e06216b58ff (commit) from 9ea8066aa67b808f71f46e346bd7a215e2a355f3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 9b8e796c37e4fa9291de31f94dbc9e06216b58ff Author: Michel Normand Date: Fri Apr 2 18:45:47 2010 +0200 lxc: add --statefile opt to lxc-checkpoint/restart based on patch from: Sukadev Bhattiprolu 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 Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/checkpoint.c |5 +++-- src/lxc/lxc.h|8 src/lxc/lxc_checkpoint.c | 31 +-- src/lxc/lxc_restart.c| 20 ++-- src/lxc/restart.c|6 +++--- 5 files changed, 37 insertions(+), 33 deletions(-) hooks/post-receive -- lxc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. f78a1f32f41f6acbbf0b78e6498736dbd22e2301
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via f78a1f32f41f6acbbf0b78e6498736dbd22e2301 (commit) from 9b8e796c37e4fa9291de31f94dbc9e06216b58ff (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit f78a1f32f41f6acbbf0b78e6498736dbd22e2301 Author: Daniel Lezcano Date: Fri Apr 2 23:37:42 2010 +0200 fix when console is not specified When no console is specified, do not try to setup the console. Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/conf.c|4 +++- src/lxc/console.c |8 2 files changed, 11 insertions(+), 1 deletions(-) hooks/post-receive -- lxc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 305bc646f5a579fb258a66dd34f4d9488d0d08fe
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lxc".
The branch, master has been updated
via 305bc646f5a579fb258a66dd34f4d9488d0d08fe (commit)
via 2b30b861579107f638d0c5b6ce22dbedf99fa4b7 (commit)
via 7adff31cbb521d52c31a3e6e2447db8bcd8e3784 (commit)
via 91480a0f0a62732f3115d556b689d62d574294ae (commit)
via 563f2f2ccd2891661836c96f92f047a735355c1b (commit)
via 3bdf52d753ecf347b3b5cbff97675032f2de3e5e (commit)
via e0f888d910c2680acf6267391f88ab75ef66771f (commit)
from f78a1f32f41f6acbbf0b78e6498736dbd22e2301 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 305bc646f5a579fb258a66dd34f4d9488d0d08fe
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
Fail gracefully with attach
Fail when we try to attach to an non existing container
Signed-off-by: Daniel Lezcano
commit 2b30b861579107f638d0c5b6ce22dbedf99fa4b7
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
change to the same directory when attaching
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
commit 7adff31cbb521d52c31a3e6e2447db8bcd8e3784
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
fork/exec after attach
The command to attach has to be fork/exec.
Signed-off-by: Daniel Lezcano
commit 91480a0f0a62732f3115d556b689d62d574294ae
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
restart the container at reboot
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
commit 563f2f2ccd2891661836c96f92f047a735355c1b
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
shutdown the container when powering off the container
This patch allows to shutdown the container when the system
is powered off in the container.
Signed-off-by: Daniel Lezcano
commit 3bdf52d753ecf347b3b5cbff97675032f2de3e5e
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
Store the container name in the handler
Store the container in the handler, so it is accessible
everywhere.
Signed-off-by: Daniel Lezcano
commit e0f888d910c2680acf6267391f88ab75ef66771f
Author: Daniel Lezcano
Date: Thu Apr 8 09:44:23 2010 +0200
count the number of tasks in the container
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
---
Summary of changes:
src/lxc/Makefile.am |6 +-
src/lxc/cgroup.c | 27 +++
src/lxc/cgroup.h |2 +-
src/lxc/commands.c|7 ++
src/lxc/conf.c|6 --
src/lxc/conf.h|1 +
src/lxc/confile.c | 30 ++--
src/lxc/lxc.h |3 +-
src/lxc/lxc_attach.c | 78 -
src/lxc/lxc_start.c | 19 --
src/lxc/mainloop.c|6 ++
src/lxc/start.c | 26 ++-
src/lxc/start.h |1 +
src/lxc/utmp.c| 157 +
src/lxc/{version.c => utmp.h} |9 +--
15 files changed, 331 insertions(+), 47 deletions(-)
create mode 100644 src/lxc/utmp.c
copy src/lxc/{version.c => utmp.h} (86%)
hooks/post-receive
--
lxc
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] detecting reboot/halt...
Michael Tokarev wrote: > I come across a series of patches to implement > reboot/halt of a container. Patches were discussed > before, but I had no time to look at that stuff in > more detail... > The problem. The current detection is based on the > content of container's /var/run/utmp. This is goood > provided the container actually touches that file, > but this is not true for "single-application" > containers, i.e. the ones without full init.d > system. Mmmh, yes that's something I thought about but I assumed an application container will not do 'shutdown' or/and run as root. But maybe I missed one kind of application, do you have in mind a particular one ? > There are only two reliable ways to get this to work: > it's either catching sys_reboot() (for which kernel > support/changes is needed), or replacing poweroff or > halt (or introducing a separate utility) which will > notify the parent process about the event in some > way (sending signal, connecting to a socket, writing > something to a pipe and the like). The first solution (catch at the kernel level) is a better solution covering all the cases. Adding extra utilities is not easy to manage because of the OS update and package dependencies. > I remember something of that sort were proposed > too, but I can't find the details now. Are there > some patches or git branch with that stuff? Yep, I did a quick hack in sys_reboot sending a SIGPWR to the parent of the pid namespace when this one is not the init_pid_ns, but I didn't had time to propose/send an acceptable version and argue for it on lkml@/contain...@. Furthermore, before sending a patch to the kernel, we have to be sure this problem can't be solved from userspace first. Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] detecting reboot/halt...
Michael Tokarev wrote: > 08.04.2010 11:56, Michael Tokarev wrote: > [] >> The problem. The current detection is based on the >> content of container's /var/run/utmp. This is goood >> provided the container actually touches that file, >> but this is not true for "single-application" >> containers, i.e. the ones without full init.d >> system. > > And one more problem: this does not work if the container > mounts a separate tmpfs on top of /var/run (which is > quite typical nowadays). (Sure it can be mounted from > the outside too, in which case the detection will work, > but the point is that this detection is quite fragile). That's correct. Good point. Let's assume the current shutdown/reboot handling code is a transient code solving a part of the problem and let's move this discussion to the containers@ mailing list, and add the missing feature in the kernel. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Unshare user namespace as well
Mikhail Gusarov wrote:
> Unshare user namespace to make sure setrlimit and other per-user limits are
> accounted properly in containers
>
> Signed-off-by: Mikhail Gusarov
> ---
> src/lxc/start.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/lxc/start.c b/src/lxc/start.c
> index 3b5023c..f1ae2fa 100644
> --- a/src/lxc/start.c
> +++ b/src/lxc/start.c
> @@ -450,7 +450,7 @@ int lxc_spawn(const char *name, struct lxc_handler
> *handler, char *const argv[])
> return -1;
> }
>
> - clone_flags = CLONE_NEWUTS|CLONE_NEWPID|CLONE_NEWIPC|CLONE_NEWNS;
> + clone_flags =
> CLONE_NEWUTS|CLONE_NEWPID|CLONE_NEWIPC|CLONE_NEWNS|CLONE_NEWUSER;
> if (!lxc_list_empty(&handler->conf->network)) {
>
> clone_flags |= CLONE_NEWNET;
Thanks Mikhail for the patch. I will apply it.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] OOPS on lxc-stop
Andrey Rahmatullin wrote: > Hello. > When I run lxc-stop for my Debian container, my system OOPSes. This is not > 100% reproducible, though. I could catch only a part of the OOPS report > using netconsole: > > > [ 9243.740626] Oops: [#1] PREEMPT > [ 9243.740648] last sysfs file: /sys/devices/platform/w83627hf.656/fan1_input > [ 9243.740655] Modules linked in: veth netconsole configfs cdc_acm > nf_conntrack_ftp iptable_mangle radeon ttm drm_kms_helper drm i2c_algo_bit > i2c_core vboxnetadp vboxnetflt vboxdrv w83627hf hwmon_vid aes_i586 > aes_generic af_packet ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt > ppp_generic slhc sit tunnel4 bridge stp llc ipv6 via_rhine mii ipt_LOG > xt_limit ipt_REJECT xt_tcpudp xt_state xt_mac iptable_nat nf_nat > nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_filter ip_tables > x_tables nls_cp1251 nls_cp866 vfat fat ext3 jbd mbcache arc4 ecb rt61pci > crc_itu_t rt2x00pci snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer > snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd rt2x00lib > sr_mod cdrom processor fan thermal mac80211 thermal_sys usb_storage > usb_libusual serial_core soundcore hwmon hid_a4tech button pata_via cfg80211 > uhci_hcd eeprom_93cx6 fuse via_agp agpgart evdev usbhid hid ehci_hcd usbcore > nls_base dm_mod [last unloaded: nf_conntrack_ftp] > [ 9243.741009] > [ 9243.741009] Pid: 22287, comm: init Not tainted 2.6.34-wrar-2 #1 > KT600-8237/KT600-8237 > [ 9243.741009] EIP: 0060:[] EFLAGS: 00210086 CPU: 0 > [ 9243.741009] EIP is at set_next_entity+0xd/0x117 > [ 9243.741009] EAX: eeb050c0 EBX: ECX: EDX: > [ 9243.741009] ESI: eeb050c0 EDI: c04734ac EBP: ed625df4 ESP: ed625de4 > [ 9243.741009] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 > [ 9243.741009] Process init (pid: 22287, ti=ed625000 task=f36818c0 > task.ti=ed625000) > [ 9243.741009] Stack: > > This is 2.6.34-rc2, though I IIRC I had these crashes on .33 too. > At the first glance I would say it is related to the FAIR_SCHEDULER. After having multiple Oops on my host, I decided to disable this option in the kernel. It is hard to reproduce, and with a few clues it is difficult to report the problem to l...@. Does sysrq + t show something ? Or the host is definitively stuck ? Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] share_via_fs patch for 2.6.33 ?
Julian Thomé wrote:
Hello mailing list,
Daniel Lezcano wrote a patch to make it possible to connect to a unix
domain socket, which belongs to another network namespace.
The patch from Daniel Lezcano is as follows:
I refreshed it against 2.6.33 and put in attachment. Compiled but not
tested ;)
Hope that helps.
-- Daniel
Subject: share af_unix socket through fs
From: Daniel Lezcano
This patch allows to connect to a socket belonging to another
network namespace but visible via the file system.
The 'host' network namespace has to allow another network
namespace to use its sockets via sysctl:
echo 1 > /proc/sys/net/unix/share_via_fs
Signed-off-by: Daniel Lezcano
---
include/linux/sysctl.h |1 +
include/net/netns/unix.h |1 +
net/unix/af_unix.c |4 +++-
net/unix/sysctl_net_unix.c |8
4 files changed, 13 insertions(+), 1 deletion(-)
Index: linux-2.6/include/net/netns/unix.h
===
--- linux-2.6.orig/include/net/netns/unix.h
+++ linux-2.6/include/net/netns/unix.h
@@ -7,6 +7,7 @@
struct ctl_table_header;
struct netns_unix {
int sysctl_max_dgram_qlen;
+ boolsysctl_share_via_fs;
struct ctl_table_header *ctl;
};
Index: linux-2.6/net/unix/af_unix.c
===
--- linux-2.6.orig/net/unix/af_unix.c
+++ linux-2.6/net/unix/af_unix.c
@@ -292,7 +292,8 @@ struct sock *unix_find_socket_byinode(st
&unix_socket_table[i->i_ino & (UNIX_HASH_SIZE - 1)]) {
struct dentry *dentry = unix_sk(s)->dentry;
- if (!net_eq(sock_net(s), net))
+ if (!sock_net(s)->unx.sysctl_share_via_fs &&
+ !net_eq(sock_net(s), net))
continue;
if (dentry && dentry->d_inode == i) {
@@ -2229,6 +2230,7 @@ static int unix_net_init(struct net *net
int error = -ENOMEM;
net->unx.sysctl_max_dgram_qlen = 10;
+ net->unx.sysctl_share_via_fs = false;
if (unix_sysctl_register(net))
goto out;
Index: linux-2.6/net/unix/sysctl_net_unix.c
===
--- linux-2.6.orig/net/unix/sysctl_net_unix.c
+++ linux-2.6/net/unix/sysctl_net_unix.c
@@ -22,6 +22,13 @@ static ctl_table unix_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "share_via_fs",
+ .data = &init_net.unx.sysctl_share_via_fs,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{ }
};
@@ -40,6 +47,7 @@ int unix_sysctl_register(struct net *net
goto err_alloc;
table[0].data = &net->unx.sysctl_max_dgram_qlen;
+ table[1].data = &net->unx.sysctl_share_via_fs;
net->unx.ctl = register_net_sysctl_table(net, unix_path, table);
if (net->unx.ctl == NULL)
goto err_reg;
Index: linux-2.6/include/linux/sysctl.h
===
--- linux-2.6.orig/include/linux/sysctl.h
+++ linux-2.6/include/linux/sysctl.h
@@ -289,6 +289,7 @@ enum
NET_UNIX_DESTROY_DELAY=1,
NET_UNIX_DELETE_DELAY=2,
NET_UNIX_MAX_DGRAM_QLEN=3,
+ NET_UNIX_SHARE_VIA_FS=4,
};
/* /proc/sys/net/netfilter */
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC crash
Elias Olivares wrote:
> Hello,
>
> Here a new lxc critical crash :
>
> I've created an LXC container and when I download something on the web (using
> wget) the host crash and an error message appears on the screen.
> Unfortunately all is installed on a dedicated server and I only can do a
> screenshot of the call stack. (provided on email attachement).
>
> More information about this crash :
>
> I use a debian Squeeze 64bits with the 2.6.32 kernel and LXC v 0.6.5
>
> My lxc config file :
>
> lxc.utsname =
> lxc.tty = 9
> lxc.pts = 1024
> lxc.network.type = veth
> lxc.network.flags = up
> lxc.network.link = br0
> lxc.network.name = eth0
> lxc.network.mtu = 1500
> lxc.network.hwaddr = C6:E9:94:1B:07:71
> #lxc.mount = $MNTFILE
> lxc.rootfs =
> lxc.cgroup.devices.deny = a
> # /dev/null and zero
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> # consoles
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> # /dev/{,u}random
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> # rtc
> lxc.cgroup.devices.allow = c 254:0 rwm
>
Hi Elias,
what is the network configuration of the host ? I see you are using a
bridge. Is there any ebtables rules ?
Thanks
-- Daniel
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] share_via_fs patch for 2.6.33 ?
Daniel Lezcano wrote: > Julian Thomé wrote: >> Hello mailing list, >> >> Daniel Lezcano wrote a patch to make it possible to connect to a unix >> domain socket, which belongs to another network namespace. >> >> The patch from Daniel Lezcano is as follows: > > I refreshed it against 2.6.33 and put in attachment. Compiled but not > tested ;) > > Hope that helps. That helped ? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] share_via_fs patch for 2.6.33 ?
Ryousei Takano wrote: > Hi Daniel, > > On Apr 17, 2010, at 4:10 AM, Daniel Lezcano wrote: > >> Daniel Lezcano wrote: >>> Julian Thomé wrote: >>>> Hello mailing list, >>>> >>>> Daniel Lezcano wrote a patch to make it possible to connect to a unix >>>> domain socket, which belongs to another network namespace. >>>> >>>> The patch from Daniel Lezcano is as follows: >>> I refreshed it against 2.6.33 and put in attachment. Compiled but not >>> tested ;) >>> >>> Hope that helps. >> That helped ? >> > It is useful for me. I want a handy method to communicate between a > container and the host OS. > Do you have plan to push it to the mainline kernel? I saw Eric Biederman (Cc'ed) has a pending patchset in http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-2.6.33-nsfd-v5.git;a=summary where he's addressing the af_unix across namespaces. Eric do you plan to push the patchset to the mainline ? Thanks -- Daniel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [Fwd: Re: [PATCH net-2.6] packet : remove init_net restriction]
FYI. Original Message Subject:Re: [PATCH net-2.6] packet : remove init_net restriction Date: Fri, 16 Apr 2010 15:41:26 -0700 (PDT) From: David Miller To: daniel.lezc...@free.fr CC: net...@vger.kernel.org References: <1271322674-21726-1-git-send-email-daniel.lezc...@free.fr> From: Daniel Lezcano Date: Thu, 15 Apr 2010 11:11:14 +0200 > The af_packet protocol is used by Perl to do ioctls as reported by > Stephane Riviere: > > "Net::RawIP relies on SIOCGIFADDR et SIOCGIFHWADDR to get the IP and MAC > addresses of the network interface." > > But in a new network namespace these ioctl fail because it is disabled for > a namespace different from the init_net_ns. > > These two lines should not be there as af_inet and af_packet are > namespace aware since a long time now. I suppose we forget to remove these > lines because we sent the af_packet first, before af_inet was supported. > > Signed-off-by: Daniel Lezcano > Reported-by: Stephane Riviere Applied, thanks! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. f2faa8fab9b15637582f7610e6b7b59261e58488
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via f2faa8fab9b15637582f7610e6b7b59261e58488 (commit) via 4d2e2ec66c9fadd4aea0090475cbf87e1b42c1a0 (commit) via 99a6af5202bdf8688ad0b5255cfa95addf3fc794 (commit) via 7d1635085fc0157282039585805189cc657f8235 (commit) via 3cfc0f3a6577266993cd37a097165df9488c7584 (commit) via e4b3fe5833cf5e8cb85389ceed8a00254c87b01f (commit) via b78b21258cc26682641bd72fd8fc10d1c6140e33 (commit) via becc0400fc83516b05a8e76f2cdfbf452cc46c94 (commit) via 94b81f611fde1efdda844171d7b0d1f2d8f86ce6 (commit) via a941cc0bf6c215079f56d68930370dcd8c6002af (commit) via d72d3d7b1685a68d0e72c648dff4ec3a3ed82082 (commit) via b89885d89696cdb79495b12b97d80d02e1c3f3fc (commit) via dcb7e5d5d25a3f2adbff8f40a1a87423307ce8fe (commit) via 26b2d1526876e6155066fece0f1c703cbed322a1 (commit) via 501cbc717f4a6d9cace36ea78c88d9f00e9b7fdb (commit) via 883a816820b9384f475a8a82d10b07482d5cf340 (commit) via affaa6da9dd10a99b9f60e24ceb3a216d56fcba1 (commit) via 698287d8cfab848ed62020116488b737aef0876b (commit) from 305bc646f5a579fb258a66dd34f4d9488d0d08fe (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit f2faa8fab9b15637582f7610e6b7b59261e58488 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 add fd to ignore to lxc_check_inherited function Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 4d2e2ec66c9fadd4aea0090475cbf87e1b42c1a0 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 lxc: move lxc_unlink_nsgroup out of lxc_fini to be able to have lxc_fini symetric with lxc_init Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 99a6af5202bdf8688ad0b5255cfa95addf3fc794 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 lxc: child failing before container rename do the same checking as already done in lxc/restart.c Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 7d1635085fc0157282039585805189cc657f8235 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 lxc: remove unused lxc_bridge_detach Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 3cfc0f3a6577266993cd37a097165df9488c7584 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 lxc: remove perror call in nl.c (V2) There is only one such perror call, so remove it in nl.c In this same patch, verify that all functions of nl.c and network.c are reporting a -errno value in case of error; value that is reported in lxc log by the callers in conf.c Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit e4b3fe5833cf5e8cb85389ceed8a00254c87b01f Author: gk...@linux.vnet.ibm.com Date: Thu Apr 29 10:03:59 2010 +0200 lxc: introduce lxc-kill command (v4) lxc-kill send a signal to the process 1 of the container. If this command is used on an application container ran by lxc-execute, the lxc-init will receive the signal and will forward it to the process 2 which is the command specified in the command line. Signed-off-by: Greg Kurz Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit b78b21258cc26682641bd72fd8fc10d1c6140e33 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 man update lxc.conf reformating given examples and add reference to examples directory. Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit becc0400fc83516b05a8e76f2cdfbf452cc46c94 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 man update lxc-create lxc-destroy Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit 94b81f611fde1efdda844171d7b0d1f2d8f86ce6 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 man update lxc-execute and lxc-start (V2) Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit a941cc0bf6c215079f56d68930370dcd8c6002af Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 man update lxc update lxc man page to better explain: * the notions of persistent and volatil container. * the difference between lxc-execute and lxc-start commands Signed-off-by: Michel Normand Signed-off-by: Daniel Lezcano commit d72d3d7b1685a68d0e72c648dff4ec3a3ed82082 Author: Michel Normand Date: Thu Apr 29 10:03:59 2010 +0200 lxc: add usage and help to lxc-n
Re: [lxc-devel] [PATCH] Unshare user namespace as well
Mikhail Gusarov wrote:
> Unshare user namespace to make sure setrlimit and other per-user limits are
> accounted properly in containers
>
> Signed-off-by: Mikhail Gusarov
> ---
> src/lxc/start.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/lxc/start.c b/src/lxc/start.c
> index 3b5023c..f1ae2fa 100644
> --- a/src/lxc/start.c
> +++ b/src/lxc/start.c
> @@ -450,7 +450,7 @@ int lxc_spawn(const char *name, struct lxc_handler
> *handler, char *const argv[])
> return -1;
> }
>
> - clone_flags = CLONE_NEWUTS|CLONE_NEWPID|CLONE_NEWIPC|CLONE_NEWNS;
> + clone_flags =
> CLONE_NEWUTS|CLONE_NEWPID|CLONE_NEWIPC|CLONE_NEWNS|CLONE_NEWUSER;
> if (!lxc_list_empty(&handler->conf->network)) {
>
> clone_flags |= CLONE_NEWNET;
>
Hi Mikhail,
I am not sure to see all the implications of having this namespace by
default, especially for application containers which can be executed by
non-root user. I think it would make sense to make this flag optional
with the configuration.
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Unshare user namespace as well
Mikhail Gusarov wrote: > Daniel. > > >> Unshare user namespace to make sure setrlimit and other per-user > >> limits are accounted properly in containers > > [skip] > > DL> I am not sure to see all the implications of having this namespace > DL> by default, especially for application containers which can be > DL> executed by non-root user. I think it would make sense to make this > DL> flag optional with the configuration. > > Fully agree. I don't use LXC at the moment, so don't expect new patch > From me -- I will scratch one when I get to using LXC again unless > someone else implements it before. > Ok, thanks Mikhail. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] share_via_fs patch for 2.6.33 ?
Julian Thomé wrote: > > Is the share_via_fs patch intended to be integrated into the kernel ? Not in this form. From the userspace pov, there is no changes, but in the kernel there are some cleanup and robustness to do around SCM_CREDENTIALS and co. I think nobody will be against sharing af_unix across the namespaces and the patchset will be likely merged upstream IMO, it is just a question of time for writing, testing and sending the patchset out. Something I don't have for the moment :( -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] share_via_fs patch for 2.6.33 ?
Julian Thomé wrote: > > Is the share_via_fs patch intended to be integrated into the kernel ? Not in this form. From the userspace pov, there is no changes, but in the kernel there are some cleanup and robustness to do around SCM_CREDENTIALS and co. I think nobody will be against sharing af_unix across the namespaces and the patchset will be likely merged upstream IMO, it is just a question of time for writing, testing and sending the patchset out. Something I don't have for the moment :( -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote:
> Ferenc Wagner writes:
>
>> Daniel Lezcano writes:
>>
>>> Ferenc Wagner wrote:
>>>
>>>> Daniel Lezcano 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
> From: Ferenc Wagner
> Date: Thu, 6 May 2010 14:47:39 +0200
> Subject: [PATCH] no need to use a temporary directory for pivoting
>
> 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
> ---
> src/lxc/conf.c | 28 +++-
> 1 files changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index b27a11d..4379a32 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -588,37 +588,15 @@ static int setup_rootfs_pivot_root(const char *rootfs,
> const char *pivotdir)
>
> static int setup_rootfs(const char *rootfs, const char *pivotdir)
> {
> - char *tmpname;
> - int ret = -1;
> -
> if (!rootfs)
> return 0;
>
> - tmpname = tempnam("/tmp", "lxc-rootfs");
> - if (!tmpname) {
> - SYSERROR("failed to generate temporary name");
> - return -1;
> - }
> -
> - if (mkdir(tmpname, 0700)) {
> - SYSERROR("failed to create temporary directory '%s'", tmpname);
> - return -1;
> - }
> -
> - if (mount(rootfs, tmpname, "none", MS_BIND|MS_REC, NULL)) {
> - SYSERROR("failed to mount '%s'->'%s'", rootfs, tmpname);
> - goto out;
> - }
> -
> - if (setup_rootfs_pivot_root(tmpname, pivotdir)) {
> + if (setup_rootfs_pivot_root(rootfs, pivotdir)) {
> ERROR("failed to pivot_root to '%s'", rootfs);
> - goto out;
> + return -1;
> }
>
> - ret = 0;
> -out:
> - rmdir(tmpname);
> - return ret;
> + return 0;
> }
>
> static int setup_pts(int pts)
Thanks, I will test it with another patch I have in my backlog fixing
the pivot_root. I Cc'ed the lxc-devel mailing list which is more
adequate for this kind of discussion.
Thanks again.
-- Daniel
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-unshare woes and signal forwarding in lxc-start
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> >>>> Ferenc Wagner wrote: >>>> >>>> >>>>> I'd like to use lxc-start as a wrapper, invisible to the parent and >>>>> the (jailed) child. Of course I could hack around this by not >>>>> exec-ing lxc-start but keeping the shell around, trap all signals and >>>>> lxc-killing them forward. But it's kind of ugly in my opinion. >>>>> >>>> >>>> Ok, got it. I think that makes sense to forward the signals, >>>> especially for job management. What signals do you want to forward? >>>> >>> Basically all of them. I couldn't find a definitive list of signals >>> used for job control in SGE, but the following is probably a good >>> approximation: SIGTTOU, SIGTTIN, SIGUSR1, SIGUSR2, SIGCONT, SIGWINCH and >>> SIGTSTP. >>> >> Yes, that could be a good starting point. I was wondering about >> SIGSTOP being sent to lxc-start which is not forwardable of course, is >> it a problem ? >> > > I suppose not, SIGSTOP and SIGKILL are impossible to use in application- > specific ways. On the other hand, SIGXCPU and SIGXFSZ should probably > be forwarded, too. Naturally, this business can't be perfected, but a > "good enough" solution could still be valuable. > Agree. >>> Looking at the source, the SIGCHLD mechanism could be >>> mimicked, but LXC_TTY_ADD_HANDLER may get in the way. >>> >> We should remove LXC_TTY_ADD_HANDLER and do everything in the signal >> handler of SIGCHLD by extending the handler. I have a pending fix >> changing a bit the signal handler function. >> > > Could you please send along your pending fix? I'd like to experiment > with signal forwarding, but without stomping on that. > Sure, no problem. > I noticed something strange: > > # lxc-start -n jail -s lxc.mount.entry="/ /tmp/jail none bind 0 0" -s > lxc.rootfs=/tmp/jail -s lxc.pivotdir=/mnt /bin/sleep 1000 > (in another terminal) > # lxc-ps --lxc > CONTAINERPID TTY TIME CMD > jail4173 pts/100:00:00 sleep > # kill 4173 > (this does not kill the sleep!) > # strace -p 4173 > Process 4173 attached - interrupt to quit > restart_syscall(<... resuming interrupted call ...> = ? ERESTART_RESTARTBLOCK > (To be restarted) > --- SIGTERM (Terminated) @ 0 (0) --- > Process 4173 detached > # lxc-ps --lxc > CONTAINERPID TTY TIME CMD > jail4173 pts/100:00:00 sleep > # fgrep -i sig /proc/4173/status > SigQ: 1/16382 > SigPnd: > SigBlk: > SigIgn: > SigCgt: > # kill -9 4173 > > That is, the jailed sleep process could be killed by SIGKILL only, even > though (according to strace) SIGTERM was delivered and it isn't handled > specially. Why does this happen? > I sent a separate email for this problem in order to avoid confusion with the signal forwarding discussion. >>> I'm also worried about signals sent to the whole process group: they >>> may be impossible to distinguish from the targeted signals and thus >>> can't propagate correctly. >>> >> >> Good point. Maybe we can setpgrp the first process of the container? >> > > We've got three options: > A) do nothing, as now > B) forward to our child > C) forward to our child's process group > > The signal could arrive because it was sent to > 1) the PID of lxc-start > 2) the process group of lxc-start > > If we don't put the first process of the container into a new process > group (as now), this is what happens: > > AB C > 1 swallowedOKothers also killed > 2 OK child gets extraeverybody gets extra > > If we put the first process of the container into a new process group: > > AB C > 1 swallowedOKothers also killed > 2 swallowed only the child killed OK > > Neither is a clear winner, although the latter is somewhat more > symmetrical. I'm not sure about wanting all this configurable... > hmm ... Maybe Greg, (it's an expert with signals and processes), has an idea on how to deal with that. -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 82d89dce377300f774afc9163778bfeb247bcc57
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 82d89dce377300f774afc9163778bfeb247bcc57 (commit) via 15cd25fdcd937105b205233a9a7ec61099fd71ef (commit) from f2faa8fab9b15637582f7610e6b7b59261e58488 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 82d89dce377300f774afc9163778bfeb247bcc57 Author: Daniel Lezcano Date: Fri May 7 14:37:05 2010 +0200 more robustness against SIGCHLD 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 commit 15cd25fdcd937105b205233a9a7ec61099fd71ef Author: Daniel Lezcano Date: Fri May 7 14:37:05 2010 +0200 do not exit mainloop when child is stopped 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 --- Summary of changes: src/lxc/start.c | 56 -- 1 files changed, 53 insertions(+), 3 deletions(-) hooks/post-receive -- lxc -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote:
Ferenc Wagner writes:
Daniel Lezcano writes:
Ferenc Wagner wrote:
Daniel Lezcano 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
From: Ferenc Wagner
Date: Thu, 6 May 2010 14:47:39 +0200
Subject: [PATCH] no need to use a temporary directory for pivoting
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
---
src/lxc/conf.c | 28 +++-
1 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index b27a11d..4379a32 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -588,37 +588,15 @@ static int setup_rootfs_pivot_root(const char *rootfs,
const char *pivotdir)
static int setup_rootfs(const char *rootfs, const char *pivotdir)
{
- char *tmpname;
- int ret = -1;
-
if (!rootfs)
return 0;
- tmpname = tempnam("/tmp", "lxc-rootfs");
- if (!tmpname) {
- SYSERROR("failed to generate temporary name");
- return -1;
- }
-
- if (mkdir(tmpname, 0700)) {
- SYSERROR("failed to create temporary directory '%s'", tmpname);
- return -1;
- }
-
- if (mount(rootfs, tmpname, "none", MS_BIND|MS_REC, NULL)) {
- SYSERROR("failed to mount '%s'->'%s'", rootfs, tmpname);
- goto out;
- }
-
- if (setup_rootfs_pivot_root(tmpname, pivotdir)) {
+ if (setup_rootfs_pivot_root(rootfs, pivotdir)) {
ERROR("failed to pivot_root to '%s'", rootfs);
- goto out;
+ return -1;
}
- ret = 0;
-out:
- rmdir(tmpname);
- return ret;
+ return 0;
}
static int setup_pts(int pts)
We can't simply remove it because of the pivot_root which returns EBUSY.
I suppose it's coming from:
"new_root and put_old must not be on the same file system as the current
root."
But as we will pivot_root right after, we won't reuse the real rootfs,
so we can safely use the host /tmp.
I tried the following patch and it worked.
Comments ?
Subject: no need to use a temporary directory for pivoting
From: Ferenc Wagner
Ferenc Wagner writes:
> Daniel Lezcano writes:
>
>> Ferenc Wagner wrote:
>>
>>> Daniel Lezcano 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 f
[lxc-devel] [GIT] lxc branch, master, updated. 25368b5249509aa21167b7ea4193e281f0091f55
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lxc".
The branch, master has been updated
via 25368b5249509aa21167b7ea4193e281f0091f55 (commit)
via bf6cc73696e485c40494bf5269f374f5a56316e7 (commit)
via 8208b295ab1589bdfec00193fb4e6534743edff5 (commit)
via 10e657e5e802c260f97716171e39e0e014f59a65 (commit)
via 2f462f4b9bc89958c53741239a6c6955f4f34120 (commit)
via 0b7a8353353e284c474be04976e0a015cfd618d2 (commit)
via 1b09f2c057205db6f31caa76c3605eb0dc7eec86 (commit)
via 5c2940600e301a62dbf8fac3ed00f466003bdadb (commit)
from 82d89dce377300f774afc9163778bfeb247bcc57 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 25368b5249509aa21167b7ea4193e281f0091f55
Author: Ferenc Wagner
Date: Mon May 10 11:50:10 2010 +0200
no need to use a temporary directory for pivoting
Ferenc Wagner writes:
> Daniel Lezcano writes:
>
>> Ferenc Wagner wrote:
>>
>>> Daniel Lezcano 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
Signed-off-by: Daniel Lezcano
commit bf6cc73696e485c40494bf5269f374f5a56316e7
Author: Daniel Lezcano
Date: Mon May 10 11:50:10 2010 +0200
Make dynamic busybox supported
Bind mount host library path.
Weird but some distro provide busybox as a dynamically linked binary.
Signed-off-by: Daniel Lezcano
commit 8208b295ab1589bdfec00193fb4e6534743edff5
Author: Guillaume Zitta
Date: Mon May 10 11:50:10 2010 +0200
make lxc-checkconfig more explicit
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
Modified-by: Daniel Lezcano
Signed-off-by: Guillaume Zitta
commit 10e657e5e802c260f97716171e39e0e014f59a65
Author: Daniel Lezcano
Date: Mon May 10 11:50:10 2010 +0200
add missing /dev/pts directory
Signed-off-by: Daniel Lezcano
commit 2f462f4b9bc89958c53741239a6c6955f4f34120
Author: Daniel Lezcano
Date: Mon May 10 11:50:09 2010 +0200
update INSTALL file
"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
Reported-by: Jamal Hadi Salim
commit 0b7a8353353e284c474be04976e0a015cfd618d2
Author: Daniel LEzcano
Date: Mon May 10 11:50:09 2010 +0200
factor out pivot_root code
Clean up and factor a bit the pivot_root code.
Signed-off-by: Daniel Lezcano
commit 1b09f2c057205db6
Re: [lxc-devel] [Lxc-users] lxc-start leaves temporary pivot dir behind
[ ... ] >> >> For my purposes the patch below works fine. I only run applications, >> though, not full systems, so wider testing is definitely needed. >> >> Thanks, >> Feri. Applied but bind mounting /tmp instead of creating a temporary directory. http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=commit;h=25368b5249509aa21167b7ea4193e281f0091f55 Thanks -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote:
> Daniel Lezcano writes:
>
>
>> Ferenc Wagner wrote:
>>
>>
>>> Ferenc Wagner writes:
>>>
>>>
>>>> Daniel Lezcano writes:
>>>>
>>>>
>>>>> Ferenc Wagner wrote:
>>>>>
>>>>>
>>>>>> Daniel Lezcano 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.
>>>
>>> >From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001
>>> From: Ferenc Wagner
>>> Date: Thu, 6 May 2010 14:47:39 +0200
>>> Subject: [PATCH] no need to use a temporary directory for pivoting
>>> [...]
>>>
>> We can't simply remove it because of the pivot_root which returns EBUSY.
>> I suppose it's coming from: "new_root and put_old must not be on the
>> same file system as the current root."
>>
>
> Hmm, this could indeed be a problem if lxc.rootfs is on the current root
> file system. I didn't consider pivoting to the same FS, but looks like
> this is the very reason for the current complexity in the architecture.
>
> Btw. is this really a safe thing to do, to pivot into a subdirectory of
> a file system? Is there really no way out of that?
>
It seems pivot_root on the same fs works if an intermediate mount point
is inserted between old_root and new_root but at the cost of having a
lazy unmount when we unmount the old rootfs filesystems . I didn't find
a better solution in order to allow the rootfs to be a directory with a
full files system tree.
I am looking at making possible to specify a rootfs which is a file
system image or a block device. I am not sure this should be done by lxc
but looking forward ...
>> But as we will pivot_root right after, we won't reuse the real rootfs,
>> so we can safely use the host /tmp.
>>
>
> That will cause problems if rootfs is under /tmp, don't you think?
>
Right :)
> Actually, I'm not sure you can fully solve this. If rootfs is a
> separate file system, this is only much ado about nothing. If rootfs
> isn't a separate filesystem, you can't automatically find a good place
> and also clean it up.
Maybe a single /tmp/lxc directory may be used as the mount points are
private to the container. So it would be acceptable to have a single
directory for N containers, no ?
> So why not require that rootfs is a separate
> filesystem, and let the user deal with it by doing the necessary bind
> mount in the lxc config?
>
Hmm, that will break the actual user configurations.
We can add a WARNING if rootfs is not a separate file system and provide
the ability to let the user to do whatever he wants, IMO if it is well
documented it is not a problem.
>> --- lxc.orig/src/lxc/conf.c
>> +++ lxc/src/lxc/conf.c
>> @@ -581,37 +581,24 @@ static int setup_rootfs_pivot_root(const
>>
>> static int setup_rootfs(const char *rootfs, const char *pivotdir)
>> {
>> -char *tmpname;
>> -int ret = -1;
>> +const char *tmpfs = "/tmp";
>>
>> if (!rootfs)
>> return 0;
>>
>> -tmpname = tempnam("/tmp", "lxc-rootfs");
>> -if (!tmpname) {
>> -SYSERROR("failed to generate temporary name");
>> +if (mount(rootfs, tmpfs, "none", MS_BIND|MS_REC, NULL)) {
>> +SYSERROR("failed to mount '%s'->'%s'", rootfs, "/tmp");
>>
>
> You probably meant tmpfs instead of "/tmp" in SYSERROR() above.
>
yep.
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> >>>> We can't simply remove it because of the pivot_root which returns >>>> EBUSY. I suppose it's coming from: "new_root and put_old must not >>>> be on the same file system as the current root." >>>> >>> Hmm, this could indeed be a problem if lxc.rootfs is on the current root >>> file system. I didn't consider pivoting to the same FS, but looks like >>> this is the very reason for the current complexity in the architecture. >>> >>> Btw. is this really a safe thing to do, to pivot into a subdirectory of >>> a file system? Is there really no way out of that? >>> >> It seems pivot_root on the same fs works if an intermediate mount >> point is inserted between old_root and new_root but at the cost of >> having a lazy unmount when we unmount the old rootfs filesystems. >> > > After pivoting? Could you please illustrate this? > After the pivot_root syscall, we have oldroot and newroot. oldroot is underneath newroot, so after pivot_root, we can still access /oldroot. We want to umount the oldroot dir of course, but before umounting it, we have to umount all the subdirectories. When everything is unmounted, we finish to umount /oldroot. But in some circumstances, this umount fails with EBUSY, so we "detach" the directory with the MNT_DETACH option. http://sourceforge.net/mailarchive/message.php?msg_name=4B5B6DA5.6050302%40free.fr >> I am looking at making possible to specify a rootfs which is a file >> system image or a block device. I am not sure this should be done by >> lxc but looking forward ... >> > > A device could be easily mounted by the user or by an lxc.mount.entry, > so I don't think it needs special consideration. > There is the file system automatic detection of the image if the image is specified in the mount entry. I already coded that, but we can postpone that for the moment and focus on the pivot_root. >>>> But as we will pivot_root right after, we won't reuse the real >>>> rootfs, so we can safely use the host /tmp. >>>> >>> That will cause problems if rootfs is under /tmp, don't you think? >>> >> Right :) >> > > Btw. my use case is exactly that: I mostly want to prune the namespace > of the container, so I bind mount / to /tmp/.../jail and a couple of > things (but not everything!) below that, and set rootfs=/tmp/.../jail. > Ok, will fix that. >>> Actually, I'm not sure you can fully solve this. If rootfs is a >>> separate file system, this is only much ado about nothing. If rootfs >>> isn't a separate filesystem, you can't automatically find a good >>> place and also clean it up. >>> >> Maybe a single /tmp/lxc directory may be used as the mount points are >> private to the container. So it would be acceptable to have a single >> directory for N containers, no ? >> > > Then why not /usr/lib/lxc/pivotdir or something like that? Such a > directory could belong to the lxc package and not clutter up /tmp. As > you pointed out, this directory would always be empty in the outer name > space, so a single one would suffice. Thus there would be no need > cleaning it up, either. > Agree. Shall we consider $(prefix)/var/run/lxc ? >>> So why not require that rootfs is a separate filesystem, and let the >>> user deal with it by doing the necessary bind mount in the lxc >>> config? >>> >> >> Hmm, that will break the actual user configurations. >> > > Yes, sadly. > > >> We can add a WARNING if rootfs is not a separate file system and >> provide the ability to let the user to do whatever he wants, IMO if it >> is well documented it is not a problem. >> > > Sure. It adds some complexity to the code, but lxc is there to help > doing common tasks. Now the question is: if rootfs is a separate file > system (which includes bind mounts), is the superfluous rbind of the > original root worth skipping, or should we just do it to avoid needing > an extra code path? > Good question. IMO, skipping the rbind is ok for this case but it may be interesting from a coding point of view to have a single place identified for the rootfs (especially for mounting an image). I will cook a patchset to fix the rootfs location and then we can look at removing the superfluous rbind. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] halt and restart bugs
Denis Rizaev wrote: > Hi folks. > I'm using latest lxc git tools on ubuntu host with debian containers. > And there are some bugs: > 1) In ubuntu, the default runlevel is 2, not 3. That's why reboot and halt > aren't handled properly. I've fixed it — patch is attached. But it's a > distro-specific patch, so I think we need another distro-agnostic solution, > maybe config option for runlevels? > Thanks for investigating the problem. I don't know how to deal with that, we discussed with Michael Tokarev about the shutdown / reboot problem and we agree the right solution is to have the kernel to notify the cinit's parent when sys_reboot is called. The present solution is a temporary 'hack' to fix up the current kernel leak functionality. So yes, adding a run level config option may do the trick for the moment. > 2) If we are in lxc-console and we type "reboot", container will not reboot, > it just halts — error log is attached. To reboot container we need to retire > from console quickly with C-a q after "reboot" command. > Good catch. Will fix that. Thanks -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] define a mount point for the rootfs
The previous code was creating a temporary directory /tmp/lxc- to mount the rootfs, this is needed to separate the filesystem for the pivot_root, when the rootfs and the host fs are the same. According to the pivot_root man page: "new_root and put_old must not be on the same file system as the current root." Unfortunately, /tmp was populated with a temporary directory which was never removed and furthermore, as Michael Tokarev pointed it, we can not mount on read-only system fs on the host due to this directory creation. A dirty fix was made to use /tmp to mount the rootfs, but of course that will prevent to put the rootfs in /tmp. This patchset address these problems by setting a default mount point, $localstatedir/run/lxc, (it is up to the user to create this directory when installing lxc by a manual mkdir, a rpm, a deb or whatever). May be /var/run/lxc is not good place ... Just let me know. If the user wants to override this mount point, then he can use the configuration option 'lxc.rootfs.mount='. TODO : check if we can get rid of this rbind mount if rootfs and hostfs are not on the same fs. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 1/5] whitespace cleanup in configure.ac
From: Daniel Lezcano Mindless changes by removing whitespace. Signed-off-by: Daniel Lezcano --- configure.ac | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 4c8c50f..c6cac11 100644 --- a/configure.ac +++ b/configure.ac @@ -55,9 +55,9 @@ AC_DEFINE_UNQUOTED(LXCPATH, "$LXCPATH") AC_DEFINE_UNQUOTED(LXCLIBEXECDIR, "$LIBEXECDIR") AC_CHECK_HEADERS([linux/netlink.h linux/genetlink.h], - [], - AC_MSG_ERROR([netlink headers not found. Please install the linux kernel headers.]), - [#include + [], + AC_MSG_ERROR([netlink headers not found. Please install the linux kernel headers.]), + [#include ]) AC_CHECK_HEADERS([sys/capability.h], [], AC_MSG_ERROR([please install libcap-devel.]), @@ -76,12 +76,12 @@ if test "x$GCC" = "xyes"; then fi AC_CONFIG_FILES([ -Makefile + Makefile lxc.pc lxc.spec -config/Makefile + config/Makefile -doc/Makefile + doc/Makefile doc/lxc-create.sgml doc/lxc-destroy.sgml doc/lxc-execute.sgml @@ -116,7 +116,7 @@ AC_CONFIG_FILES([ scripts/lxc-fedora scripts/lxc-sshd -src/Makefile + src/Makefile src/lxc/Makefile src/lxc/lxc-ps src/lxc/lxc-ls -- 1.6.3.3 -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 2/5] add a configure option to set a rootfs mount point
From: Daniel Lezcano
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
---
configure.ac |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index c6cac11..c8669b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,12 +47,21 @@ AC_ARG_WITH([config-path],
[lxc configuration repository path]
)], [], [with_config_path="${localstatedir}/lib/lxc"])
+AC_ARG_WITH([rootfs-path],
+ [AC_HELP_STRING(
+ [--with-rootfs-path=dir],
+ [lxc rootfs mount point]
+ )], [], [with_rootfs_path="${localstatedir}/run/lxc"])
+
AS_AC_EXPAND(LXC_GENERATE_DATE, "$(date)")
AS_AC_EXPAND(LXCPATH, "${with_config_path}")
+AS_AC_EXPAND(LXCROOTFSMOUNT, "${with_rootfs_path}")
AH_TEMPLATE([LXCPATH], [lxc configuration repository])
AH_TEMPLATE([LXCLIBEXECDIR], [lxc executable library path])
+AH_TEMPLATE([LXCROOTFSMOUNT], [lxc default rootfs mount point])
AC_DEFINE_UNQUOTED(LXCPATH, "$LXCPATH")
AC_DEFINE_UNQUOTED(LXCLIBEXECDIR, "$LIBEXECDIR")
+AC_DEFINE_UNQUOTED(LXCROOTFSMOUNT, "$LXCROOTFSMOUNT")
AC_CHECK_HEADERS([linux/netlink.h linux/genetlink.h],
[],
--
1.6.3.3
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 4/5] add lxc.rootfs.mount config option
From: Daniel Lezcano
Define lxc.rootfs.mount option in order to override the default
mount point for rootfs.
Signed-off-by: Daniel Lezcano
---
src/lxc/conf.h|1 +
src/lxc/confile.c | 18 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/src/lxc/conf.h b/src/lxc/conf.h
index 14c931d..8451266 100644
--- a/src/lxc/conf.h
+++ b/src/lxc/conf.h
@@ -170,6 +170,7 @@ struct lxc_console {
*/
struct lxc_rootfs {
char *path;
+ char *mount;
char *pivot;
};
diff --git a/src/lxc/confile.c b/src/lxc/confile.c
index dd9f2cb..8c1b3dd 100644
--- a/src/lxc/confile.c
+++ b/src/lxc/confile.c
@@ -48,6 +48,7 @@ static int config_tty(const char *, char *, struct lxc_conf
*);
static int config_cgroup(const char *, char *, struct lxc_conf *);
static int config_mount(const char *, char *, struct lxc_conf *);
static int config_rootfs(const char *, char *, struct lxc_conf *);
+static int config_rootfs_mount(const char *, char *, struct lxc_conf *);
static int config_pivotdir(const char *, char *, struct lxc_conf *);
static int config_utsname(const char *, char *, struct lxc_conf *);
static int config_network_type(const char *, char *, struct lxc_conf *);
@@ -77,6 +78,7 @@ static struct config config[] = {
{ "lxc.tty", config_tty },
{ "lxc.cgroup", config_cgroup },
{ "lxc.mount",config_mount},
+ { "lxc.rootfs.mount", config_rootfs_mount },
{ "lxc.rootfs", config_rootfs },
{ "lxc.pivotdir", config_pivotdir },
{ "lxc.utsname", config_utsname },
@@ -652,6 +654,22 @@ static int config_rootfs(const char *key, char *value,
struct lxc_conf *lxc_conf
return 0;
}
+static int config_rootfs_mount(const char *key, char *value, struct lxc_conf
*lxc_conf)
+{
+ if (strlen(value) >= MAXPATHLEN) {
+ ERROR("%s path is too long", value);
+ return -1;
+ }
+
+ lxc_conf->rootfs.mount = strdup(value);
+ if (!lxc_conf->rootfs.mount) {
+ SYSERROR("failed to duplicate string '%s'", value);
+ return -1;
+ }
+
+ return 0;
+}
+
static int config_pivotdir(const char *key, char *value, struct lxc_conf
*lxc_conf)
{
if (strlen(value) >= MAXPATHLEN) {
--
1.6.3.3
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 5/5] use defined rootfs mount point
From: Daniel Lezcano
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
---
src/lxc/conf.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 55eb715..2b8ddf4 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -582,19 +582,22 @@ static int setup_rootfs_pivot_root(const char *rootfs,
const char *pivotdir)
static int setup_rootfs(const struct lxc_rootfs *rootfs)
{
- const char *tmpfs = "/tmp";
+ char *mpath = LXCROOTFSMOUNT;
if (!rootfs->path)
return 0;
- if (mount(rootfs->path, tmpfs, "none", MS_BIND|MS_REC, NULL)) {
- SYSERROR("failed to mount '%s'->'%s'", rootfs->path, "/tmp");
+ if (rootfs->mount)
+ mpath = rootfs->mount;
+
+ if (mount(rootfs->path, mpath, "none", MS_BIND|MS_REC, NULL)) {
+ SYSERROR("failed to mount '%s'->'%s'", rootfs->path, mpath);
return -1;
}
- DEBUG("mounted '%s' on '%s'", rootfs->path, tmpfs);
+ DEBUG("mounted '%s' on '%s'", rootfs->path, mpath);
- if (setup_rootfs_pivot_root(tmpfs, rootfs->pivot)) {
+ if (setup_rootfs_pivot_root(mpath, rootfs->pivot)) {
ERROR("failed to pivot_root to '%s'", rootfs->pivot);
return -1;
}
--
1.6.3.3
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 3/5] encapsulate rootfs data in a structure
From: Daniel Lezcano
We have pivot_dir and rootfs defined in lxc_conf structure.
Let's encapsulate them in a rootfs structure.
Signed-off-by: Daniel Lezcano
---
src/lxc/conf.c| 32 +---
src/lxc/conf.h| 14 --
src/lxc/confile.c |8
src/lxc/console.c |6 +++---
src/lxc/utmp.c|6 +++---
5 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 2575413..55eb715 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -374,7 +374,8 @@ static int setup_utsname(struct utsname *utsname)
return 0;
}
-static int setup_tty(const char *rootfs, const struct lxc_tty_info *tty_info)
+static int setup_tty(const struct lxc_rootfs *rootfs,
+const struct lxc_tty_info *tty_info)
{
char path[MAXPATHLEN];
int i;
@@ -384,7 +385,7 @@ static int setup_tty(const char *rootfs, const struct
lxc_tty_info *tty_info)
struct lxc_pty_info *pty_info = &tty_info->pty_info[i];
snprintf(path, sizeof(path), "%s/dev/tty%d",
-rootfs ? rootfs : "", i + 1);
+rootfs->path ? rootfs->path : "", i + 1);
/* At this point I can not use the "access" function
* to check the file is present or not because it fails
@@ -579,22 +580,22 @@ static int setup_rootfs_pivot_root(const char *rootfs,
const char *pivotdir)
return 0;
}
-static int setup_rootfs(const char *rootfs, const char *pivotdir)
+static int setup_rootfs(const struct lxc_rootfs *rootfs)
{
const char *tmpfs = "/tmp";
- if (!rootfs)
+ if (!rootfs->path)
return 0;
- if (mount(rootfs, tmpfs, "none", MS_BIND|MS_REC, NULL)) {
- SYSERROR("failed to mount '%s'->'%s'", rootfs, "/tmp");
+ if (mount(rootfs->path, tmpfs, "none", MS_BIND|MS_REC, NULL)) {
+ SYSERROR("failed to mount '%s'->'%s'", rootfs->path, "/tmp");
return -1;
}
- DEBUG("mounted '%s' on '%s'", rootfs, tmpfs);
+ DEBUG("mounted '%s' on '%s'", rootfs->path, tmpfs);
- if (setup_rootfs_pivot_root(tmpfs, pivotdir)) {
- ERROR("failed to pivot_root to '%s'", rootfs);
+ if (setup_rootfs_pivot_root(tmpfs, rootfs->pivot)) {
+ ERROR("failed to pivot_root to '%s'", rootfs->pivot);
return -1;
}
@@ -640,16 +641,17 @@ out:
return 0;
}
-static int setup_console(const char *rootfs, const struct lxc_console *console)
+static int setup_console(const struct lxc_rootfs *rootfs,
+const struct lxc_console *console)
{
char path[MAXPATHLEN];
struct stat s;
/* We don't have a rootfs, /dev/console will be shared */
- if (!rootfs)
+ if (!rootfs->path)
return 0;
- snprintf(path, sizeof(path), "%s/dev/console", rootfs);
+ snprintf(path, sizeof(path), "%s/dev/console", rootfs->path);
if (access(path, F_OK)) {
WARN("rootfs specified but no console found");
@@ -1415,17 +1417,17 @@ int lxc_setup(const char *name, struct lxc_conf
*lxc_conf)
return -1;
}
- if (setup_console(lxc_conf->rootfs, &lxc_conf->console)) {
+ if (setup_console(&lxc_conf->rootfs, &lxc_conf->console)) {
ERROR("failed to setup the console for '%s'", name);
return -1;
}
- if (setup_tty(lxc_conf->rootfs, &lxc_conf->tty_info)) {
+ if (setup_tty(&lxc_conf->rootfs, &lxc_conf->tty_info)) {
ERROR("failed to setup the ttys for '%s'", name);
return -1;
}
- if (setup_rootfs(lxc_conf->rootfs, lxc_conf->pivotdir)) {
+ if (setup_rootfs(&lxc_conf->rootfs)) {
ERROR("failed to set rootfs for '%s'", name);
return -1;
}
diff --git a/src/lxc/conf.h b/src/lxc/conf.h
index d0232db..14c931d 100644
--- a/src/lxc/conf.h
+++ b/src/lxc/conf.h
@@ -163,6 +163,17 @@ struct lxc_console {
};
/*
+ * Defines a structure to store the rootfs location, the
+ * optionals pivot_root, rootfs mount paths
+ * @rootfs : a path to the rootfs
+ * @pivot_root : a path to a pivot_root location to be used
+ */
+struct lxc_rootfs {
+ char *path;
+ char *pivot;
+};
+
+/*
* Defines the global container configuration
* @rootfs : root directory to run the container
* @pivotdir : pivotdir pat
Re: [lxc-devel] Containerized syslog
Jean-Philippe Menil wrote: > Hi, > > I'm playing with containers under debian (squeeze, 2.6.33.3) with the > lxc tools. > I'm really happy about all the features (attach veth on bridge, filter > with iptables inside the containers, etc ...), and i was thinking to > replace some of our vservers (and maybe some of our kvm) with this > solution. > > But actually, i experiment a problem with the iptables logs: > i've iptables on the host to filter some container, basically a squid > proxy. I've another container who act as router, and he has his own > iptables inside. > All the log are deported to a dedicated syslog server. > It appear that, the iptables log of the host are also deported by the > syslog container (proxy). > > Some of our guest (container, vserver, etc ) are administer by other > sys-admin, that should not have access to theses informations. > > This point is blocking me today, before going into production with > containers. > > I've seen some patch made by Jean-Marc Pigeon about this problem, > but they have not been commited. I thing a consensus was not reach. The big deal with syslog is netfilter logs in an interrupt context where it is difficult to find the right log buffer ring as we are not in the process context making possible to identify the namespace. IMHO, there are two parts to implement, (1) multiple instances of /dev/log with a new ring buffer each time attached to the file and (2) add an iptables rules to specify the file to log. This approach allows to get rid of namespace (in all the cases the clone flags are exhausted now), and provides a generic mechanism for other use cases (eg. separate logs for iptables) different from a container specific problem. This is from a kernel POV, but from the userspace POV, that will means the iptables rules in the vps configuration files should be modified, I don't know if it's acceptable. > Is there any reason for that? > Can someone advice me to circumvent this problem? I don't know a workaround for this problem. Thanks -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> >>>> Ferenc Wagner wrote: >>>> >>>> >>>>> Actually, I'm not sure you can fully solve this. If rootfs is a >>>>> separate file system, this is only much ado about nothing. If rootfs >>>>> isn't a separate filesystem, you can't automatically find a good >>>>> place and also clean it up. >>>>> >>>> Maybe a single /tmp/lxc directory may be used as the mount points are >>>> private to the container. So it would be acceptable to have a single >>>> directory for N containers, no ? >>>> >>> Then why not /usr/lib/lxc/pivotdir or something like that? Such a >>> directory could belong to the lxc package and not clutter up /tmp. As >>> you pointed out, this directory would always be empty in the outer name >>> space, so a single one would suffice. Thus there would be no need >>> cleaning it up, either. >>> >> Agree. Shall we consider $(prefix)/var/run/lxc ? >> > > Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot > if /var/run is on tmpfs. This isn't variable data either, that's why I > recommended /usr above. > Good point. I will change that to /usr/$(libdir)/lxc and let the distro maintainer to choose a better place if he wants with the configure option. >>> Now the question is: if rootfs is a separate file system (which >>> includes bind mounts), is the superfluous rbind of the original root >>> worth skipping, or should we just do it to avoid needing an extra >>> code path? >>> >> Good question. IMO, skipping the rbind is ok for this case but it may >> be interesting from a coding point of view to have a single place >> identified for the rootfs (especially for mounting an image). I will >> cook a patchset to fix the rootfs location and then we can look at >> removing the superfluous rbind. >> > > I'm testing your patchset now. So far it seems to work as advertised. > Cool, thanks for testing. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] remove pivotdir only if it was created by us
Ferenc Wagner wrote: > The removal does not account for possible leading path components that > were also created during creation of pivotdir. > > Signed-off-by: Ferenc Wagner > --- > +1 -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 9232212afdad25536afc8d241606e00eac3b0c87
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 9232212afdad25536afc8d241606e00eac3b0c87 (commit) via a91d897a7b5ef5ef07ede977fa35d5895947665a (commit) via b1789442d69eb756355a53316c9dca4b74671883 (commit) via 23b7ea696bd3158ec7a0dd88cafa169e63fc8ad3 (commit) via 33fcb7a0477ed37523f05e0a083046eea166acf0 (commit) via 196db713a9ab0479d1e695aa428577abedcbfa58 (commit) via 288063bd0756250ffb9a736fa075acba2249202e (commit) from 25368b5249509aa21167b7ea4193e281f0091f55 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 9232212afdad25536afc8d241606e00eac3b0c87 Author: Ferenc Wagner Date: Wed May 12 23:47:55 2010 +0200 fix typos in error messages Signed-off-by: Ferenc Wagner Signed-off-by: Daniel Lezcano commit a91d897a7b5ef5ef07ede977fa35d5895947665a Author: Ferenc Wagner Date: Wed May 12 23:47:55 2010 +0200 remove pivotdir only if it was created by us The removal does not account for possible leading path components that were also created during creation of pivotdir. Signed-off-by: Ferenc Wagner Signed-off-by: Daniel Lezcano commit b1789442d69eb756355a53316c9dca4b74671883 Author: Daniel Lezcano Date: Wed May 12 23:44:28 2010 +0200 use defined rootfs mount point 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 commit 23b7ea696bd3158ec7a0dd88cafa169e63fc8ad3 Author: Daniel Lezcano Date: Wed May 12 23:44:28 2010 +0200 add lxc.rootfs.mount config option Define lxc.rootfs.mount option in order to override the default mount point for rootfs. Signed-off-by: Daniel Lezcano commit 33fcb7a0477ed37523f05e0a083046eea166acf0 Author: Daniel Lezcano Date: Wed May 12 23:44:28 2010 +0200 encapsulate rootfs data in a structure We have pivot_dir and rootfs defined in lxc_conf structure. Let's encapsulate them in a rootfs structure. Signed-off-by: Daniel Lezcano commit 196db713a9ab0479d1e695aa428577abedcbfa58 Author: Daniel Lezcano Date: Wed May 12 23:44:28 2010 +0200 add a configure option to set a rootfs mount point 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 commit 288063bd0756250ffb9a736fa075acba2249202e Author: Daniel Lezcano Date: Wed May 12 23:44:28 2010 +0200 whitespace cleanup in configure.ac Mindless changes by removing whitespace. Signed-off-by: Daniel Lezcano --- Summary of changes: configure.ac | 23 --- src/lxc/conf.c| 53 + src/lxc/conf.h| 15 +-- src/lxc/confile.c | 26 ++ src/lxc/console.c |6 +++--- src/lxc/utmp.c|6 +++--- 6 files changed, 90 insertions(+), 39 deletions(-) hooks/post-receive -- lxc -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] remove pivotdir only if it was created by us
Ferenc Wagner wrote: > The removal does not account for possible leading path components that > were also created during creation of pivotdir. > > Signed-off-by: Ferenc Wagner > --- > Applied. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] fix typos in error messages
Ferenc Wagner wrote: > Signed-off-by: Ferenc Wagner > --- > Applied thanks. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] lxc-start leaves temporary pivot dir behind
Michael H. Warfield wrote:
> On Wed, 2010-05-12 at 23:18 +0200, Daniel Lezcano wrote:
>
>> Ferenc Wagner wrote:
>>
>>> Daniel Lezcano writes:
>>>
>>>
>>>
>>>> Ferenc Wagner wrote:
>>>>
>>>>
>>>>
>>>>> Daniel Lezcano writes:
>>>>>
>>>>>
>>>>>
>>>>>> Ferenc Wagner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Actually, I'm not sure you can fully solve this. If rootfs is a
>>>>>>> separate file system, this is only much ado about nothing. If rootfs
>>>>>>> isn't a separate filesystem, you can't automatically find a good
>>>>>>> place and also clean it up.
>>>>>>>
>>>>>>>
>>>>>> Maybe a single /tmp/lxc directory may be used as the mount points are
>>>>>> private to the container. So it would be acceptable to have a single
>>>>>> directory for N containers, no ?
>>>>>>
>>>>>>
>>>>> Then why not /usr/lib/lxc/pivotdir or something like that? Such a
>>>>> directory could belong to the lxc package and not clutter up /tmp. As
>>>>> you pointed out, this directory would always be empty in the outer name
>>>>> space, so a single one would suffice. Thus there would be no need
>>>>> cleaning it up, either.
>>>>>
>>>>>
>>>> Agree. Shall we consider $(prefix)/var/run/lxc ?
>>>>
>>>>
>>> Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot
>>> if /var/run is on tmpfs. This isn't variable data either, that's why I
>>> recommended /usr above.
>>>
>>>
>> Good point. I will change that to /usr/$(libdir)/lxc and let the distro
>> maintainer to choose a better place if he wants with the configure option.
>>
>
> Are you SURE you want /usr/${libdir}/lxc for this? Some high security
> systems might mount /usr as a separate read-only partition (OK - I'm and
> old school old fart). Part of the standard allows for /usr to be an RO
> file system.
>
I am not sure it is the right location, but lxc does not create the
directory and, as you mention, I don't want to do that due to RO fs. It
is up to the admin to configure the system with this directory.
The configure option allows to specify the location of the directory, so
I let the lxc distro maintainers to choose the location they want and to
create the directory in the package post-install section.
Furthermore, in the config option of lxc, you can change the location
with lxc.rootfs.mount=
lxc mounts only the rootfs on this directory. As we are in the private
mount namespace, the mount point is only visible from the container, and
not externally, so we can reuse this directory to mount another rootfs
for another container. In other words, one directory for all the containers.
> Wouldn't this be more appropriate in /var/${libdir}/lxc instead? Maybe
> create a .tmp directory under it or .tmp.${CTID} or something? Or,
> maybe, something under /var/${libdir}/lxc/${CTID}/tmp instead? /var is
> for things that change and vary. Wouldn't that be a better location and
> you've already got control of the /var/${libdir}/lxc location, don't
> you?
>
We are talking about the default location when nothing is specified for
the configure.
We need just one directory and I am not sure it is good to place it in
/var/lib/lxc because these are for containers configuration and the rule
is one directory in /var/lib/lxc == one container.
Putting it in /var/lib/{ctrid}/ is not good because we can spawn a
'volatile' container without a previous creation (eg. lxc-start -n foo
-f configfile, or lxc-start -n foo -s lxc.rootfs=myrootfs -s
lxc.network.type=veth ...)
But I am open if there is a better default location. /var/run/lxc was
proposed but Ferenc pointed it is mounted as a tmpfs on some distro
(like ubuntu) and we will need to create it at each reboot.
Thanks
-- Daniel
>>>>> Now the question is: if rootfs is a separate file system (which
>>>>> includes bind mounts), is the superfluous rbind of the original root
>>>>> worth skipping, or should we just do it to avoid needing an extra
>>>>> code path?
>>>>>
>>>>>
>>>> Good question. IMO, skipping the rbind is ok for this case but it may
>>>> be interesting from a coding point of view to have a single place
>>>> identified for the rootfs (especially for mounting an image). I will
>>>> cook a patchset to fix the rootfs location and then we can look at
>>>> removing the superfluous rbind.
>>>>
>>>>
>>> I'm testing your patchset now. So far it seems to work as advertised.
>>>
>>>
>> Cool, thanks for testing.
>>
>
> Regards,
> Mike
>
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> >>>> Ferenc Wagner wrote: >>>> >>>> >>>>> Daniel Lezcano writes: >>>>> >>>>> >>>>>> Ferenc Wagner wrote: >>>>>> >>>>>> >>>>>>> Actually, I'm not sure you can fully solve this. If rootfs is a >>>>>>> separate file system, this is only much ado about nothing. If rootfs >>>>>>> isn't a separate filesystem, you can't automatically find a good >>>>>>> place and also clean it up. >>>>>>> >>>>>> Maybe a single /tmp/lxc directory may be used as the mount points are >>>>>> private to the container. So it would be acceptable to have a single >>>>>> directory for N containers, no ? >>>>>> >>>>> Then why not /usr/lib/lxc/pivotdir or something like that? Such a >>>>> directory could belong to the lxc package and not clutter up /tmp. As >>>>> you pointed out, this directory would always be empty in the outer name >>>>> space, so a single one would suffice. Thus there would be no need >>>>> cleaning it up, either. >>>>> >>>> Agree. Shall we consider $(prefix)/var/run/lxc ? >>>> >>> Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot >>> if /var/run is on tmpfs. This isn't variable data either, that's why I >>> recommended /usr above. >>> >> Good point. I will change that to /usr/$(libdir)/lxc and let the >> distro maintainer to choose a better place if he wants with the >> configure option. >> > > I'm not sure what libdir is, doesn't this conflict with lxc-init? > That's in the /usr/lib/lxc directory, at least in Debian. I'd vote for > /usr/lib/lxc/oldroot in this setting. > $(libdir) is the variable defined by configure --libdir= Usually it is /usr/lib on 32bits or /usr/lib64 on 64bits. lxc-init is located in $(libexecdir), that is /usr/libexec or /libexec depending of the configure setting. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-unshare woes and signal forwarding in lxc-start
On 05/13/2010 02:22 PM, Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> >>>> Ferenc Wagner wrote: >>>> >>>> >>>>> Daniel Lezcano writes: >>>>> >>>>> >>>>>> Ferenc Wagner wrote: >>>>>> >>>>>> >>>>>>> I'd like to use lxc-start as a wrapper, invisible to the parent and >>>>>>> the (jailed) child. Of course I could hack around this by not >>>>>>> exec-ing lxc-start but keeping the shell around, trap all signals and >>>>>>> lxc-killing them forward. But it's kind of ugly in my opinion. >>>>>>> >>>>>> Ok, got it. I think that makes sense to forward the signals, >>>>>> especially for job management. What signals do you want to >>>>>> forward? >>>>>> >>>>> Basically all of them. I couldn't find a definitive list of signals >>>>> used for job control in SGE, but the following is probably a good >>>>> approximation: SIGTTOU, SIGTTIN, SIGUSR1, SIGUSR2, SIGCONT, SIGWINCH and >>>>> SIGTSTP. >>>>> >>>> Yes, that could be a good starting point. I was wondering about >>>> SIGSTOP being sent to lxc-start which is not forwardable of course, >>>> is it a problem ? >>>> >>> I suppose not, SIGSTOP and SIGKILL are impossible to use in application- >>> specific ways. On the other hand, SIGXCPU and SIGXFSZ should probably >>> be forwarded, too. Naturally, this business can't be perfected, but a >>> "good enough" solution could still be valuable. >>> >> Agree. >> > I attached a proof-of-concept patch which seems to work good enough for > me. The function names are somewhat off now, but I leave that for later. > Thanks I will play a bit with it. >>>>> Looking at the source, the SIGCHLD mechanism could be >>>>> mimicked, but LXC_TTY_ADD_HANDLER may get in the way. >>>>> >>>> We should remove LXC_TTY_ADD_HANDLER and do everything in the signal >>>> handler of SIGCHLD by extending the handler. I have a pending fix >>>> changing a bit the signal handler function. >>>> > What's the purpose of LXC_TTY_ADD_HANDLER anyway? I didn't dig into it. > We have the lxc-start process, parent of the container init, monitoring the first process of the container. This process shall exit only when it's child dies. The LXC_TTY_ADD_HANDLER is a signal handler to avoid this process to be killed by a Ctrl+C. I suppose with the signal forwarding, we can add SIGINT and SIGQUIT to the signals to be forwarded and remove LXC_TTY_* >>>>> I'm also worried about signals sent to the whole process group: they >>>>> may be impossible to distinguish from the targeted signals and thus >>>>> can't propagate correctly. >>>>> >>>> Good point. Maybe we can setpgrp the first process of the container? >>>> >>> We've got three options: >>>A) do nothing, as now >>>B) forward to our child >>>C) forward to our child's process group >>> >>> The signal could arrive because it was sent to >>>1) the PID of lxc-start >>>2) the process group of lxc-start >>> >>> If we don't put the first process of the container into a new process >>> group (as now), this is what happens: >>> >>> AB C >>> 1 swallowedOKothers also killed >>> 2 OK child gets extraeverybody gets extra >>> >>> If we put the first process of the container into a new process group: >>> >>> AB C >>> 1 swallowedOKothers also killed >>> 2 swallowed only the child killed OK >>> >>> Neither is a clear winner, although the latter is somewhat more >>> symmetrical. I'm not sure about wanting all this configurable... >>> >> hmm ... Maybe Greg, (it's an expert with signals and processes), has >> an idea on how to deal with that. >> > I'd say we should setpgrp the container init, forward all signals we > can to it, Agree. > and have a configuration option for the set of signals which > should be forwarded to the full process group of the container init. > Or does it make sense to swallow anything? > IMO sending a signal to a group means, we assume the application didn't setpgrp/setsid. AFAICS, a batch manager will spawn an application without knowledge of it's behavior. I remember a batch manager was relying on a kernel module to track the processes of the job in order to kill them all, but since the cgroup exists that is no longer needed. IMHO we can just forward the signal to the container init only and we wait a bit to check if this feature suffices. Thanks -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 1f1b18e754e4c1157ffaadeb3d0ae05e5c83cb5a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 1f1b18e754e4c1157ffaadeb3d0ae05e5c83cb5a (commit) from 9232212afdad25536afc8d241606e00eac3b0c87 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 1f1b18e754e4c1157ffaadeb3d0ae05e5c83cb5a Author: Daniel Lezcano Date: Tue May 18 17:40:04 2010 +0200 support ipv4 broadcast specification 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 --- Summary of changes: src/lxc/network.c | 112 ++-- src/lxc/network.h |7 +++- 2 files changed, 71 insertions(+), 48 deletions(-) hooks/post-receive -- lxc -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [GIT] lxc branch, master, updated. 0093bb8ced5784468daf8e66783e6be3782e8fea
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 0093bb8ced5784468daf8e66783e6be3782e8fea (commit) from 1f1b18e754e4c1157ffaadeb3d0ae05e5c83cb5a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 0093bb8ced5784468daf8e66783e6be3782e8fea Author: Daniel Lezcano Date: Tue May 18 19:13:26 2010 +0200 added locally modified files for broadcast support Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/conf.c|9 + src/lxc/conf.h|2 +- src/lxc/confile.c | 17 - 3 files changed, 18 insertions(+), 10 deletions(-) hooks/post-receive -- lxc -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] correct asprintf error checking
On 05/19/2010 08:29 PM, Nathan Lynch wrote: > asprintf(3) returns -1 (not 0) on error. > > Signed-off-by: Nathan Lynch > --- > Right :) Thanks Nathan. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] conf: remove unused code
On 05/19/2010 08:29 PM, Nathan Lynch wrote:
> Since commit ab2d32f ("Replace create/destroy by a script"),
> configure_rootfs and many of its descendents are unused; remove them.
>
> Signed-off-by: Nathan Lynch
>
I am planning to reuse this code for mounting rootfs images but that
needs some rework with the configuration.
I should have put a #if 0 section for this code and a comment ...
Thanks.
-- Daniel
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
