Re: [lxc-devel] [PATCH] define list container api
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On Wed, Oct 09, 2013 at 07:17:43AM -0500, Serge Hallyn wrote:
> > Two new commands are defined: list_defined_containers() and
> > list_active_containers(). Both take an lxcpath (NULL means
> > use the default lxcpath) and return the number of containers
> > found. If a lxc_container ** is passed in, then an array of
> > lxc_container's is returned, one for each container found.
> > The caller must then lxc_container_put() each container and
> > free the array, as shown in the new list testcase.
> >
> > Signed-off-by: Serge Hallyn
>
> Overall looks good, thanks!
>
> I just have one question/comment below that may impact memory/cpu usage
> and performance quite a bit on machines with a lot of containers.
>
> > ---
> > src/lxc/lxccontainer.c | 155
> > +
> > src/lxc/lxccontainer.h | 19 ++
> > src/tests/Makefile.am | 6 +-
> > src/tests/list.c | 57 ++
> > 4 files changed, 235 insertions(+), 2 deletions(-)
> > create mode 100644 src/tests/list.c
> >
> > diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> > index 13ed4d2..5a0edce 100644
> > --- a/src/lxc/lxccontainer.c
> > +++ b/src/lxc/lxccontainer.c
> > @@ -2744,3 +2744,158 @@ int lxc_get_wait_states(const char **states)
> > states[i] = lxc_state2str(i);
> > return MAX_STATE;
> > }
> > +
> > +
> > +bool add_to_clist(struct lxc_container ***list, struct lxc_container *c,
> > int pos)
> > +{
> > + struct lxc_container **newlist = realloc(*list, pos * sizeof(struct
> > lxc_container *));
> > + if (!newlist) {
> > + free(*list);
> > + *list = NULL;
> > + ERROR("Out of memory");
> > + return false;
> > + }
> > +
> > + *list = newlist;
> > + newlist[pos-1] = c;
> > + return true;
> > +}
> > +
> > +int list_defined_containers(const char *lxcpath, struct lxc_container
> > ***cret)
> > +{
> > + DIR *dir;
> > + int nfound = 0;
> > + struct dirent dirent, *direntp;
> > +
> > + if (!lxcpath)
> > + lxcpath = default_lxc_path();
> > +
> > + process_lock();
> > + dir = opendir(lxcpath);
> > + process_unlock();
> > +
> > + if (!dir) {
> > + SYSERROR("opendir on lxcpath");
> > + return -1;
> > + }
> > +
> > + if (cret)
> > + *cret = NULL;
> > +
> > + while (!readdir_r(dir, &dirent, &direntp)) {
> > + if (!direntp)
> > + break;
> > + if (!strcmp(direntp->d_name, "."))
> > + continue;
> > + if (!strcmp(direntp->d_name, ".."))
> > + continue;
>
> Is it actually faster or more reliable to load the whole container
> instead of just looking for direntp->d_name/config?
>
> > +
> > + struct lxc_container *c = lxc_container_new(direntp->d_name,
> > lxcpath);
Originally I had a comment there to say we might want to just
manually check for the config file. Originally I also had a
char *** passed in so you could harvest only the container
names without getting the full lxc_container structs.
What I liked about this is the ability to reuse the
lxcapi_is_defined() function and avoid reimplementing
the check - with potential for accidental divergence as
the code evolves.
Should we offer the char *** option? Or is that just
going to complicate the lua/go/python api exports?
-serge
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API errors
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi Serge,
>
>
> On Sat, Oct 5, 2013 at 12:27 AM, Serge Hallyn wrote:
>
> > Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > > Quoting S.Çağlar Onur (cag...@10ur.org):
> > > > Hi,
> > > >
> > > > src/lxc/lxccontainer.h contains two public field named error_string and
> > > > error_num. If I'm not missing anything no one seems to be using them.
> > > >
> > > > What was the intention? Should API calls set those and stop using
> > macros
> > > > like ERROR and SYSERROR?
> > >
> > > That is the idea. It's not yet clear to me how to best track that.
> > > Maybe it should become an array of strings, so that each stack layer
> > > moving up and seeing an error happened can give its own input on what
> > > it was doing. Then when lxc-start fails, we can see something like
> > >
> > > [0] failed to create container
> > > [1] failed to setup network
> > > [2] failed to create veth
> > > [3] failed to pass veth into network namespce
> > >
> > > And then yes, ERROR and SYSERROR should be reserved for the actual
> > > programs, and should spit out error stacks as well.
> >
> > So I'm thinking an API like the below. Much in bdev.c for instance can
> > be converted to PUSH_ERR. Although all the places where we have
> > fork()ed obviouslly cannot. There they'll have to keep doing ERROR(),
> > and the parent can point to the logfile for further info.
> >
>
> I'm imagining API methods themselves are going to call the clear_errors
> (i.e something like below) and the only reason to export that is to
> provide an alternative way to manage the stack? If that's the case,
> wouldn't be helpful if there will be a get_error call as well, which
> removes the last error from the stack and returns to the caller?
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 02126b2..7390cac 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -510,6 +510,8 @@ static bool lxcapi_start(struct lxc_container *c, int
> useinit, char * const argv
> if (!c->lxc_conf)
> return false;
>
> + c->clear_errors();
> +
> if ((ret = ongoing_create(c)) < 0) {
> ERROR("Error checking for incomplete creation");
> return false;
Thinking about it more, I'm less sure about sticking the
errors in the lxc_container struct. That's fine for
things like start and freeze, but not for things like
freeze or even a failed lxc_container_new().
I thought maybe it should go in thread-local storage. But
then if we end up with a crash before the caller has a
chance to write the info out to disk, we lose the info.
We could use ipc shared memory, so then we could actually
go in after the fact with a lxc-diagnose tool and get the
latest error messages for a particular (lxcpath,lxcname)
tuple. That actually seems to have the fewest downsides,
and may address all our requirements.
-serge
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] define list container api
On Thu, Oct 10, 2013 at 08:33:28AM -0500, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
> > On Wed, Oct 09, 2013 at 07:17:43AM -0500, Serge Hallyn wrote:
> > > Two new commands are defined: list_defined_containers() and
> > > list_active_containers(). Both take an lxcpath (NULL means
> > > use the default lxcpath) and return the number of containers
> > > found. If a lxc_container ** is passed in, then an array of
> > > lxc_container's is returned, one for each container found.
> > > The caller must then lxc_container_put() each container and
> > > free the array, as shown in the new list testcase.
> > >
> > > Signed-off-by: Serge Hallyn
> >
> > Overall looks good, thanks!
> >
> > I just have one question/comment below that may impact memory/cpu usage
> > and performance quite a bit on machines with a lot of containers.
> >
> > > ---
> > > src/lxc/lxccontainer.c | 155
> > > +
> > > src/lxc/lxccontainer.h | 19 ++
> > > src/tests/Makefile.am | 6 +-
> > > src/tests/list.c | 57 ++
> > > 4 files changed, 235 insertions(+), 2 deletions(-)
> > > create mode 100644 src/tests/list.c
> > >
> > > diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> > > index 13ed4d2..5a0edce 100644
> > > --- a/src/lxc/lxccontainer.c
> > > +++ b/src/lxc/lxccontainer.c
> > > @@ -2744,3 +2744,158 @@ int lxc_get_wait_states(const char **states)
> > > states[i] = lxc_state2str(i);
> > > return MAX_STATE;
> > > }
> > > +
> > > +
> > > +bool add_to_clist(struct lxc_container ***list, struct lxc_container *c,
> > > int pos)
> > > +{
> > > + struct lxc_container **newlist = realloc(*list, pos * sizeof(struct
> > > lxc_container *));
> > > + if (!newlist) {
> > > + free(*list);
> > > + *list = NULL;
> > > + ERROR("Out of memory");
> > > + return false;
> > > + }
> > > +
> > > + *list = newlist;
> > > + newlist[pos-1] = c;
> > > + return true;
> > > +}
> > > +
> > > +int list_defined_containers(const char *lxcpath, struct lxc_container
> > > ***cret)
> > > +{
> > > + DIR *dir;
> > > + int nfound = 0;
> > > + struct dirent dirent, *direntp;
> > > +
> > > + if (!lxcpath)
> > > + lxcpath = default_lxc_path();
> > > +
> > > + process_lock();
> > > + dir = opendir(lxcpath);
> > > + process_unlock();
> > > +
> > > + if (!dir) {
> > > + SYSERROR("opendir on lxcpath");
> > > + return -1;
> > > + }
> > > +
> > > + if (cret)
> > > + *cret = NULL;
> > > +
> > > + while (!readdir_r(dir, &dirent, &direntp)) {
> > > + if (!direntp)
> > > + break;
> > > + if (!strcmp(direntp->d_name, "."))
> > > + continue;
> > > + if (!strcmp(direntp->d_name, ".."))
> > > + continue;
> >
> > Is it actually faster or more reliable to load the whole container
> > instead of just looking for direntp->d_name/config?
> >
> > > +
> > > + struct lxc_container *c = lxc_container_new(direntp->d_name,
> > > lxcpath);
>
> Originally I had a comment there to say we might want to just
> manually check for the config file. Originally I also had a
> char *** passed in so you could harvest only the container
> names without getting the full lxc_container structs.
>
> What I liked about this is the ability to reuse the
> lxcapi_is_defined() function and avoid reimplementing
> the check - with potential for accidental divergence as
> the code evolves.
>
> Should we offer the char *** option? Or is that just
> going to complicate the lua/go/python api exports?
I don't think supporting both would be a problem for bindings, we'd
probably just bind them to two different functions (e.g.
lxc_list_defined_names).
I still think it'd be better to only lxc_container_new once we've
confirmed a config file exists, otherwise someone who has a rather messy
/var/lib/lxc or pass /usr/bin to -P (ok, that'd be stupid but still)
would cause a lot of locking calls and a ton of check for basically
nothing.
>
> -serge
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] lxc-start: Invalid argument - pivot_root syscall failed
Hi, guys. I'm using 1.0.0.alpha1 although I've tried with 0.8.0 also and I'm unable to start container with the following error: lxc-start: Invalid argument - pivot_root syscall failed lxc-start: failed to setup pivot root lxc-start: failed to set rootfs for 'repos' lxc-start: failed to setup the container lxc-start: invalid sequence number 1. expected 2 lxc-start: failed to spawn 'repos' I've tried mount --make-private on all mount point I've thought of with no luck. Also I've tried lxc.autodev = 1 also no luck and I guess this is relevant with systemd while this systems uses openrc as init system. Container's conf file: lxc.arch = amd64 lxc.utsname = repos lxc.rootfs = /virt/lxc/repos Distribution Gentoo. Same config works fine on another gentoo system. Although systems are completely different I think important differences are: 1. init system: on laptop I'm using systemd while on server openrc 2. on server I have full system inside ram (system resides inside initramfs and after boot root stays in RAM on rootfs) # cat /proc/self/mountinfo 1 1 0:1 / / rw - rootfs rootfs rw 14 1 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw 15 1 0:13 / /run rw,nosuid,nodev,relatime - tmpfs tmpfs rw,mode=755 16 1 0:5 / /dev rw,nosuid,relatime - devtmpfs udev rw,size=10240k,nr_inodes=4081011,mode=755 17 16 0:10 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000 18 16 0:14 / /dev/shm rw,nosuid,nodev,noexec,relatime - tmpfs shm rw 19 1 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw 20 19 0:12 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime - securityfs securityfs rw 21 19 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime - debugfs debugfs rw 22 19 0:16 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - tmpfs cgroup_root rw,size=10240k,mode=755 23 22 0:17 / /sys/fs/cgroup/openrc rw,nosuid,nodev,noexec,relatime - cgroup openrc rw,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc 24 22 0:18 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime - cgroup cpuset rw,cpuset,clone_children 25 22 0:19 / /sys/fs/cgroup/cpu rw,nosuid,nodev,noexec,relatime - cgroup cpu rw,cpu 26 22 0:20 / /sys/fs/cgroup/cpuacct rw,nosuid,nodev,noexec,relatime - cgroup cpuacct rw,cpuacct 27 22 0:21 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime - cgroup memory rw,memory 28 22 0:22 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime - cgroup devices rw,devices 29 22 0:23 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup freezer rw,freezer 30 22 0:24 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime - cgroup blkio rw,blkio 31 22 0:25 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime - cgroup perf_event rw,perf_event 32 1 8:1 / /mnt/root rw,noatime - ext4 /dev/sda1 rw,data=ordered 33 1 254:1 / /virt rw,relatime - ext4 /dev/mapper/virt rw,data=ordered So any suggestions are welcome. Output of -l DEBUG -o test.debug in attachment. Just for record, I've opened bug report https://github.com/lxc/lxc/issues/61 for this. TIA, -- Peter. lxc-start 1381350553.618 WARN lxc_log - lxc_log_init called with log already initialized lxc-start 1381350553.618 INFO lxc_apparmor - apparmor_load - apparmor is disabled lxc-start 1381350553.618 DEBUGlxc_start - sigchild handler set lxc-start 1381350553.618 DEBUGlxc_console - opening /dev/tty for console peer lxc-start 1381350553.618 DEBUGlxc_console - using '/dev/tty' as console lxc-start 1381350553.618 DEBUGlxc_console - 2890 got SIGWINCH fd 9 lxc-start 1381350553.618 DEBUGlxc_console - set winsz dstfd:6 cols:112 rows:26 lxc-start 1381350553.618 INFO lxc_start - 'repos' is initialized lxc-start 1381350553.666 DEBUGlxc_start - Not dropping cap_sys_boot or watching utmp lxc-start 1381350553.666 INFO lxc_conf - opened /virt/lxc/repos.hold as fd 12 lxc-start 1381350553.667 INFO lxc_conf - 'repos' hostname has been setup lxc-start 1381350553.667 INFO lxc_conf - looking at .34 34 0:1 / / rw - rootfs rootfs rw . lxc-start 1381350553.667 INFO lxc_conf - now p is . /. lxc-start 1381350553.667 INFO lxc_conf - looking at .35 34 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw . lxc-start 1381350553.667 INFO lxc_conf - now p is . /proc. lxc-start 1381350553.667 INFO lxc_conf - looking at .36 34 0:13 / /run rw,nosuid,nodev,relatime - tmpfs tmpfs rw,mode=755 . lxc-start 1381350553.667 INFO lxc_conf - now p is . /run. lxc-start 1381350553.667 INFO lxc_conf - looking at .37 34 0:5 / /dev rw,nosuid,relatime - devtmpfs udev rw,size=10240k,nr_inodes=4081011,mode=755 . lxc-start 1381350553.667 INFO lxc_conf - now p is . /dev. lxc-start 1381350553.667 INFO lxc_conf - looking at .38 37 0:10 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000 . lxc-start
[lxc-devel] [PATCH] fix clone prototype
gcc was complaining with:
reboot.c:33: error: conflicting types for ‘clone’
/usr/include/bits/sched.h:83: note: previous declaration of ‘clone’ was here
Signed-off-by: Dwight Engen
---
src/tests/reboot.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/tests/reboot.c b/src/tests/reboot.c
index 6e12aa4..82fa5b1 100644
--- a/src/tests/reboot.c
+++ b/src/tests/reboot.c
@@ -30,7 +30,7 @@
#include
#include
-int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
+int clone(int (*fn)(void *), void *child_stack, int flags, void *arg, ...);
static int do_reboot(void *arg)
{
--
1.7.1
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Migration of bug tracker from sourceforge to github
On Wed, 2 Oct 2013 17:31:07 -0400 Stéphane Graber wrote: > Hey everyone, > > Just wanted to let you know that I just finished going through the 80 > or so bug reports we had on sourceforge, closing any that weren't > affecting master anymore, moving a few to github and fixing another > bunch. > > So as of now, the only two remaining sourceforge based services are: > - website > - mailing lists > > My next step will be the website which I'll spend some time to migrate > over to http://linuxcontainers.org > > The idea is to have a simple website, with a few examples and pointers > to documentation for most distributions. I know we tend to be bad at > updating websites, so my goal is to make it so we don't have to :) Hi Stéphane, A low maintenance, simple website sounds like a good idea. I like the new clean look. I didn't really see a good spot in what is already there for distro specfic pointers / docs, but once there is such a spot I'd like to add a couple of pointers to some Oracle Linux lxc resources: docs: http://docs.oracle.com/cd/E37670_01/E37355/html/ol_containers.html yum : http://public-yum.oracle.com/ yum playground channel for more recent lxc packages: https://blogs.oracle.com/wim/entry/introducing_the_oracle_linux_playground If you want me to take a stab at adding a distro specific section to what there I'm happy to check it out and do so. Thanks! > That new website is backed by git (git://github.com/lxc/lxc.github.io) > so if you want to help, add content to the site, send patches my way. > -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 92cbfd: template: Improved lxc-plamo template
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 92cbfdaf682dca9cf60243f23c2e911181bfc7ab https://github.com/lxc/lxc/commit/92cbfdaf682dca9cf60243f23c2e911181bfc7ab Author: KATOH Yasufumi Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M templates/lxc-plamo.in Log Message: --- template: Improved lxc-plamo template lxc-plamo now work with any distribution other than Plamo Linux. Signed-off-by: KATOH Yasufumi Signed-off-by: TAMUKI Shoichi Acked-by: Stéphane Graber -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 9aad9d: Add an OpenMandriva distro lxc-openmandriva templa...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 9aad9d12c9625aef9bd9386dc762e6299354b714 https://github.com/lxc/lxc/commit/9aad9d12c9625aef9bd9386dc762e6299354b714 Author: Alexander Khryukin Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M configure.ac M templates/Makefile.am A templates/lxc-openmandriva.in Log Message: --- Add an OpenMandriva distro lxc-openmandriva template Signed-off-by: Alexander Khryukin Acked-by: Stéphane Graber Commit: f1d8e7ed86f056a1a764c276a5be1894839c6029 https://github.com/lxc/lxc/commit/f1d8e7ed86f056a1a764c276a5be1894839c6029 Author: Alexander Khryukin Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M .gitignore Log Message: --- fix .gitignore file and add a little improvements to openmandriva template Signed-off-by: Alexander Khryukin Acked-by: Stéphane Graber Commit: edcf9b59793ba9c8f3117d8c5d62d7cb5db73b27 https://github.com/lxc/lxc/commit/edcf9b59793ba9c8f3117d8c5d62d7cb5db73b27 Author: Alexander Khryukin Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M templates/lxc-openmandriva.in Log Message: --- minor cleanup in template and add systemd_configure function with openmandriva-related tricks Signed-off-by: Alexander Khryukin Acked-by: Stéphane Graber Commit: aa1c458caa3a6e8ad76350da88bf82904c690994 https://github.com/lxc/lxc/commit/aa1c458caa3a6e8ad76350da88bf82904c690994 Author: Alexander Khryukin Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M templates/lxc-openmandriva.in Log Message: --- fix typo and minor cleanup Signed-off-by: Alexander Khryukin Acked-by: Stéphane Graber Commit: 7d35d3a7e1b93766025398ec74df901bfbbedbf0 https://github.com/lxc/lxc/commit/7d35d3a7e1b93766025398ec74df901bfbbedbf0 Author: Alexander Khryukin Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M templates/lxc-openmandriva.in Log Message: --- add $arch to cache path Signed-off-by: Alexander Khryukin Acked-by: Stéphane Graber Compare: https://github.com/lxc/lxc/compare/92cbfdaf682d...7d35d3a7e1b9 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] fix clone prototype
Quoting Dwight Engen (dwight.en...@oracle.com):
> gcc was complaining with:
> reboot.c:33: error: conflicting types for ‘clone’
> /usr/include/bits/sched.h:83: note: previous declaration of ‘clone’ was here
>
> Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
> ---
> src/tests/reboot.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/tests/reboot.c b/src/tests/reboot.c
> index 6e12aa4..82fa5b1 100644
> --- a/src/tests/reboot.c
> +++ b/src/tests/reboot.c
> @@ -30,7 +30,7 @@
> #include
> #include
>
> -int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
> +int clone(int (*fn)(void *), void *child_stack, int flags, void *arg, ...);
>
> static int do_reboot(void *arg)
> {
> --
> 1.7.1
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] f3cef1: fix clone prototype
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: f3cef1cbe2835668036d40bc88c2e546868bc0ea https://github.com/lxc/lxc/commit/f3cef1cbe2835668036d40bc88c2e546868bc0ea Author: Dwight Engen Date: 2013-10-10 (Thu, 10 Oct 2013) Changed paths: M src/tests/reboot.c Log Message: --- fix clone prototype gcc was complaining with: reboot.c:33: error: conflicting types for ‘clone’ /usr/include/bits/sched.h:83: note: previous declaration of ‘clone’ was here Signed-off-by: Dwight Engen Signed-off-by: Serge Hallyn -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] fix clone prototype
On Thu, Oct 10, 2013 at 12:59:04PM -0400, Dwight Engen wrote:
> gcc was complaining with:
> reboot.c:33: error: conflicting types for ‘clone’
> /usr/include/bits/sched.h:83: note: previous declaration of ‘clone’ was here
>
> Signed-off-by: Dwight Engen
Acked-by: Stéphane Graber
> ---
> src/tests/reboot.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/tests/reboot.c b/src/tests/reboot.c
> index 6e12aa4..82fa5b1 100644
> --- a/src/tests/reboot.c
> +++ b/src/tests/reboot.c
> @@ -30,7 +30,7 @@
> #include
> #include
>
> -int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
> +int clone(int (*fn)(void *), void *child_stack, int flags, void *arg, ...);
>
> static int do_reboot(void *arg)
> {
> --
> 1.7.1
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start: Invalid argument - pivot_root syscall failed
Quoting Peter Volkov (p...@gentoo.org): > Hi, guys. > > I'm using 1.0.0.alpha1 although I've tried with 0.8.0 also and I'm > unable to start container with the following error: > > lxc-start: Invalid argument - pivot_root syscall failed > lxc-start: failed to setup pivot root > lxc-start: failed to set rootfs for 'repos' > lxc-start: failed to setup the container > lxc-start: invalid sequence number 1. expected 2 > lxc-start: failed to spawn 'repos' > > I've tried mount --make-private on all mount point I've thought of with > no luck. > Also I've tried lxc.autodev = 1 also no luck and I guess this is > relevant with systemd while this systems uses openrc as init system. > > Container's conf file: > > lxc.arch = amd64 > lxc.utsname = repos > lxc.rootfs = /virt/lxc/repos > > Distribution Gentoo. Same config works fine on another gentoo system. > Although systems are completely different I think important differences > are: > 1. init system: on laptop I'm using systemd while on server openrc > 2. on server I have full system inside ram (system resides inside > initramfs and after boot root stays in RAM on rootfs) I think that's the problem. I could be wrong, but I think it's refusing ecause your root doesn't have a parent, i.e. isn't mounted somewhere. I suspect we want detect_shared_rootfs() updated to check for your rootfs being mount #1, and also return 1 in that case (meaning we will set up an environment in which you can in fact pivot_root). Is such a patch something you could write and test? thanks, -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
