[lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[Stéphane Graber]

This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.

This commit was preventing startup of containers using lxc hooks and
shutdown of all other containers, requiring the use of a good old
kill -9 to get rid of lxc-start after a container shutdown.

Signed-off-by: Stéphane Graber 
---
 src/lxc/start.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/src/lxc/start.c b/src/lxc/start.c
index a58737a..aefccd6 100644
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
@@ -198,7 +198,6 @@ static int setup_signal_fd(sigset_t *oldmask)
sigdelset(&mask, SIGILL) ||
sigdelset(&mask, SIGSEGV) ||
sigdelset(&mask, SIGBUS) ||
-   sigdelset(&mask, SIGCHLD) ||
sigprocmask(SIG_BLOCK, &mask, oldmask)) {
SYSERROR("failed to set signal mask");
return -1;
@@ -740,29 +739,10 @@ int save_phys_nics(struct lxc_conf *conf)
return 0;
 }
 
-static void sigchild_handler(int sig)
-{
-   int status;
-   pid_t child;
-
-   child = wait(&status);
-   if (child < 0) {
-   SYSERROR("SIGCHLD caught but wait() failed: %m\n");
-   return;
-   }
-
-   if (WIFSIGNALED(status))
-   ERROR("Process in the new namespace died before execve()"
- " due to signal: %i", WTERMSIG(status));
-   else if (WIFEXITED(status))
-   ERROR("Process in the new namespace died before execve()"
- " with exit code: %i", WIFEXITED(status));
-}
 
 int lxc_spawn(struct lxc_handler *handler)
 {
int failed_before_rename = 0;
-   struct sigaction act;
const char *name = handler->name;
 
if (lxc_sync_init(handler))
@@ -813,14 +793,6 @@ int lxc_spawn(struct lxc_handler *handler)
goto out_delete_net;
}
 
-   /*
-* Install a SIGCHLD handler to detect the death of the new child 
between
-* clone() and execve().
-*/
-   memset(&act, 0, sizeof(act));
-   act.sa_handler = sigchild_handler;
-   sigaction(SIGCHLD, &act, NULL);
-
/* Create a process in a new set of namespaces */
handler->pid = lxc_clone(do_start, handler, handler->clone_flags);
if (handler->pid < 0) {
-- 
1.8.1.2


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.

This commit was preventing container startup on my machine, making them
all fail with various "No such file or directory" errors.

Signed-off-by: Stéphane Graber 
---
 src/lxc/utils.c | 48 +++-
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/src/lxc/utils.c b/src/lxc/utils.c
index 9794553..e07ca7b 100644
--- a/src/lxc/utils.c
+++ b/src/lxc/utils.c
@@ -95,25 +95,39 @@ extern int get_u16(unsigned short *val, const char *arg, 
int base)
return 0;
 }
 
+static int is_all_slashes(char *path)
+{
+   while (*path && *path == '/')
+   path++;
+   if (*path)
+   return 0;
+   return 1;
+}
+
 extern int mkdir_p(char *dir, mode_t mode)
 {
-   char *tmp = dir;
-   char *orig = dir;
-   char *makeme;
-
-   do {
-   dir = tmp + strspn(tmp, "/");
-   tmp = dir + strcspn(dir, "/");
-   makeme = strndupa(orig, dir - orig);
-   if (*makeme) {
-   if (!access(makeme, F_OK))
-   return 0;
-   if (mkdir(makeme, mode)) {
-   SYSERROR("failed to create directory '%s'\n", 
makeme);
-   return -1;
-   }
-   }
-   } while(tmp != dir);
+   int ret;
+   char *d;
+
+   if (is_all_slashes(dir))
+   return 0;
+
+   d = strdup(dir);
+   if (!d)
+   return -1;
+
+   ret = mkdir_p(dirname(d), mode);
+   free(d);
+   if (ret)
+   return -1;
+
+   if (!access(dir, F_OK))
+   return 0;
+
+   if (mkdir(dir, mode)) {
+   SYSERROR("failed to create directory '%s'\n", dir);
+   return -1;
+   }
 
return 0;
 }
-- 
1.8.1.2


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[Stéphane Graber]

On 04/18/2013 10:32 AM, Stéphane Graber wrote:
> This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.
> 
> This commit was preventing startup of containers using lxc hooks and
> shutdown of all other containers, requiring the use of a good old
> kill -9 to get rid of lxc-start after a container shutdown.
> 
> Signed-off-by: Stéphane Graber 

Was directly applied to the staging branch as the issue was preventing
regular use of LXC.

> ---
>  src/lxc/start.c | 28 
>  1 file changed, 28 deletions(-)
> 
> diff --git a/src/lxc/start.c b/src/lxc/start.c
> index a58737a..aefccd6 100644
> --- a/src/lxc/start.c
> +++ b/src/lxc/start.c
> @@ -198,7 +198,6 @@ static int setup_signal_fd(sigset_t *oldmask)
>   sigdelset(&mask, SIGILL) ||
>   sigdelset(&mask, SIGSEGV) ||
>   sigdelset(&mask, SIGBUS) ||
> - sigdelset(&mask, SIGCHLD) ||
>   sigprocmask(SIG_BLOCK, &mask, oldmask)) {
>   SYSERROR("failed to set signal mask");
>   return -1;
> @@ -740,29 +739,10 @@ int save_phys_nics(struct lxc_conf *conf)
>   return 0;
>  }
>  
> -static void sigchild_handler(int sig)
> -{
> - int status;
> - pid_t child;
> -
> - child = wait(&status);
> - if (child < 0) {
> - SYSERROR("SIGCHLD caught but wait() failed: %m\n");
> - return;
> - }
> -
> - if (WIFSIGNALED(status))
> - ERROR("Process in the new namespace died before execve()"
> -   " due to signal: %i", WTERMSIG(status));
> - else if (WIFEXITED(status))
> - ERROR("Process in the new namespace died before execve()"
> -   " with exit code: %i", WIFEXITED(status));
> -}
>  
>  int lxc_spawn(struct lxc_handler *handler)
>  {
>   int failed_before_rename = 0;
> - struct sigaction act;
>   const char *name = handler->name;
>  
>   if (lxc_sync_init(handler))
> @@ -813,14 +793,6 @@ int lxc_spawn(struct lxc_handler *handler)
>   goto out_delete_net;
>   }
>  
> - /*
> -  * Install a SIGCHLD handler to detect the death of the new child 
> between
> -  * clone() and execve().
> -  */
> - memset(&act, 0, sizeof(act));
> - act.sa_handler = sigchild_handler;
> - sigaction(SIGCHLD, &act, NULL);
> -
>   /* Create a process in a new set of namespaces */
>   handler->pid = lxc_clone(do_start, handler, handler->clone_flags);
>   if (handler->pid < 0) {
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

On 04/18/2013 10:32 AM, Stéphane Graber wrote:
> This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.
> 
> This commit was preventing container startup on my machine, making them
> all fail with various "No such file or directory" errors.
> 
> Signed-off-by: Stéphane Graber 

Was directly applied to the staging branch as the issue was preventing
regular use of LXC.

> ---
>  src/lxc/utils.c | 48 +++-
>  1 file changed, 31 insertions(+), 17 deletions(-)
> 
> diff --git a/src/lxc/utils.c b/src/lxc/utils.c
> index 9794553..e07ca7b 100644
> --- a/src/lxc/utils.c
> +++ b/src/lxc/utils.c
> @@ -95,25 +95,39 @@ extern int get_u16(unsigned short *val, const char *arg, 
> int base)
>   return 0;
>  }
>  
> +static int is_all_slashes(char *path)
> +{
> + while (*path && *path == '/')
> + path++;
> + if (*path)
> + return 0;
> + return 1;
> +}
> +
>  extern int mkdir_p(char *dir, mode_t mode)
>  {
> - char *tmp = dir;
> - char *orig = dir;
> - char *makeme;
> -
> - do {
> - dir = tmp + strspn(tmp, "/");
> - tmp = dir + strcspn(dir, "/");
> - makeme = strndupa(orig, dir - orig);
> - if (*makeme) {
> - if (!access(makeme, F_OK))
> - return 0;
> - if (mkdir(makeme, mode)) {
> - SYSERROR("failed to create directory '%s'\n", 
> makeme);
> - return -1;
> - }
> - }
> - } while(tmp != dir);
> + int ret;
> + char *d;
> +
> + if (is_all_slashes(dir))
> + return 0;
> +
> + d = strdup(dir);
> + if (!d)
> + return -1;
> +
> + ret = mkdir_p(dirname(d), mode);
> + free(d);
> + if (ret)
> + return -1;
> +
> + if (!access(dir, F_OK))
> + return 0;
> +
> + if (mkdir(dir, mode)) {
> + SYSERROR("failed to create directory '%s'\n", dir);
> + return -1;
> + }
>  
>   return 0;
>  }
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] [PATCH] python: Lots of fixes in C extension

[Stéphane Graber]

Fixes a lot of issues found by a code review done by Barry Warsaw.

Those include:
 - Wrong signature for getters
 - Various memory leaks
 - Various optimizations
 - More consistent return values
 - Proper exception handling

Reported-by: Barry Warsaw 
Signed-off-by: Stéphane Graber 
---
 src/python-lxc/lxc.c | 270 +++
 1 file changed, 184 insertions(+), 86 deletions(-)

diff --git a/src/python-lxc/lxc.c b/src/python-lxc/lxc.c
index 8da6f36..85bab11 100644
--- a/src/python-lxc/lxc.c
+++ b/src/python-lxc/lxc.c
@@ -34,13 +34,19 @@ typedef struct {
 
 char**
 convert_tuple_to_char_pointer_array(PyObject *argv) {
-int argc = PyTuple_Size(argv);
+int argc = PyTuple_GET_SIZE(argv);
 int i;
 
 char **result = (char**) malloc(sizeof(char*)*argc + 1);
 
+if (result == NULL) {
+PyErr_SetNone(PyExc_MemoryError);
+return NULL;
+}
+
 for (i = 0; i < argc; i++) {
-PyObject *pyobj = PyTuple_GetItem(argv, i);
+PyObject *pyobj = PyTuple_GET_ITEM(argv, i);
+assert(pyobj != NULL);
 
 char *str = NULL;
 PyObject *pystr = NULL;
@@ -51,8 +57,17 @@ convert_tuple_to_char_pointer_array(PyObject *argv) {
 }
 
 pystr = PyUnicode_AsUTF8String(pyobj);
+if (pystr == NULL) {
+PyErr_SetString(PyExc_ValueError, "Unable to convert to UTF-8");
+free(result);
+return NULL;
+}
+
 str = PyBytes_AsString(pystr);
+assert(str != NULL);
+
 memcpy((char *) &result[i], (char *) &str, sizeof(str));
+Py_DECREF(pystr);
 }
 
 result[argc] = NULL;
@@ -82,18 +97,27 @@ Container_init(Container *self, PyObject *args, PyObject 
*kwds)
 {
 static char *kwlist[] = {"name", "config_path", NULL};
 char *name = NULL;
+PyObject *fs_config_path = NULL;
 char *config_path = NULL;
 
-if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|s", kwlist,
-  &name, &config_path))
+if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|O&", kwlist,
+  &name,
+  PyUnicode_FSConverter, &fs_config_path))
 return -1;
 
+if (fs_config_path != NULL) {
+config_path = PyBytes_AS_STRING(fs_config_path);
+assert(config_path != NULL);
+}
+
 self->container = lxc_container_new(name, config_path);
 if (!self->container) {
-fprintf(stderr, "%d: error creating lxc_container %s\n", __LINE__, 
name);
+Py_XDECREF(fs_config_path);
+fprintf(stderr, "%d: error creating container %s\n", __LINE__, name);
 return -1;
 }
 
+Py_XDECREF(fs_config_path);
 return 0;
 }
 
@@ -111,13 +135,14 @@ LXC_get_version(PyObject *self, PyObject *args)
 
 // Container properties
 static PyObject *
-Container_config_file_name(Container *self, PyObject *args, PyObject *kwds)
+Container_config_file_name(Container *self, void *closure)
 {
-return 
PyUnicode_FromString(self->container->config_file_name(self->container));
+return PyUnicode_FromString(
+self->container->config_file_name(self->container));
 }
 
 static PyObject *
-Container_defined(Container *self, PyObject *args, PyObject *kwds)
+Container_defined(Container *self, void *closure)
 {
 if (self->container->is_defined(self->container)) {
 Py_RETURN_TRUE;
@@ -127,19 +152,19 @@ Container_defined(Container *self, PyObject *args, 
PyObject *kwds)
 }
 
 static PyObject *
-Container_init_pid(Container *self, PyObject *args, PyObject *kwds)
+Container_init_pid(Container *self, void *closure)
 {
-return Py_BuildValue("i", self->container->init_pid(self->container));
+return PyLong_FromLong(self->container->init_pid(self->container));
 }
 
 static PyObject *
-Container_name(Container *self, PyObject *args, PyObject *kwds)
+Container_name(Container *self, void *closure)
 {
 return PyUnicode_FromString(self->container->name);
 }
 
 static PyObject *
-Container_running(Container *self, PyObject *args, PyObject *kwds)
+Container_running(Container *self, void *closure)
 {
 if (self->container->is_running(self->container)) {
 Py_RETURN_TRUE;
@@ -149,7 +174,7 @@ Container_running(Container *self, PyObject *args, PyObject 
*kwds)
 }
 
 static PyObject *
-Container_state(Container *self, PyObject *args, PyObject *kwds)
+Container_state(Container *self, void *closure)
 {
 return PyUnicode_FromString(self->container->state(self->container));
 }
@@ -161,9 +186,9 @@ Container_clear_config_item(Container *self, PyObject 
*args, PyObject *kwds)
 static char *kwlist[] = {"key", NULL};
 char *key = NULL;
 
-if (! PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist,
+if (! PyArg_ParseTupleAndKeywords(args, kwds, "s", kwlist,
   &key))
-Py_RETURN_FALSE;
+return NULL;
 
 if (self->container->clear_config_item(self->cont

[lxc-devel] [PATCH] utils: reimplement/fix mkdir_p()

[Richard Weinberger]

Reimplement mkdir_p() such that it:
 ...handles relativ paths correctly. (currently it crashes)
 ...does not rely on dirname().
 ...is not recursive.
 ...is shorter. ;-)

Signed-off-by: Richard Weinberger 
---
 src/lxc/utils.c | 46 +++---
 1 file changed, 15 insertions(+), 31 deletions(-)

diff --git a/src/lxc/utils.c b/src/lxc/utils.c
index e07ca7b..6a154f9 100644
--- a/src/lxc/utils.c
+++ b/src/lxc/utils.c
@@ -95,39 +95,23 @@ extern int get_u16(unsigned short *val, const char *arg, 
int base)
return 0;
 }
 
-static int is_all_slashes(char *path)
-{
-   while (*path && *path == '/')
-   path++;
-   if (*path)
-   return 0;
-   return 1;
-}
-
 extern int mkdir_p(char *dir, mode_t mode)
 {
-   int ret;
-   char *d;
-
-   if (is_all_slashes(dir))
-   return 0;
-
-   d = strdup(dir);
-   if (!d)
-   return -1;
-
-   ret = mkdir_p(dirname(d), mode);
-   free(d);
-   if (ret)
-   return -1;
-
-   if (!access(dir, F_OK))
-   return 0;
-
-   if (mkdir(dir, mode)) {
-   SYSERROR("failed to create directory '%s'\n", dir);
-   return -1;
-   }
+   char *tmp = dir;
+   char *orig = dir;
+   char *makeme;
+
+   do {
+   dir = tmp + strspn(tmp, "/");
+   tmp = dir + strcspn(dir, "/");
+   makeme = strndupa(orig, dir - orig);
+   if (*makeme) {
+   if (mkdir(makeme, mode) && errno != EEXIST) {
+   SYSERROR("failed to create directory '%s'\n", 
makeme);
+   return -1;
+   }
+   }
+   } while(tmp != dir);
 
return 0;
 }
-- 
1.8.1.4


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] utils: reimplement/fix mkdir_p()

[Richard Weinberger]

Am 17.04.2013 22:49, schrieb Serge Hallyn:
> Quoting Richard Weinberger (rich...@nod.at):
>> Am 17.04.2013 18:00, schrieb Serge Hallyn:
>>> Quoting Richard Weinberger (rich...@nod.at):
 Reimplement mkdir_p() such that it:
   ...handles relativ paths correctly. (currently it crashes)
   ...does not rely on dirname().
   ...is not recursive.
   ...is shorter. ;-)
>>>
>>> Looks good, thanks.  Yeah I prefer non-recursive.  Three
>>> comments though,
>>>
 Signed-off-by: Richard Weinberger 
 ---
   src/lxc/utils.c | 48 +---
   1 file changed, 17 insertions(+), 31 deletions(-)

 diff --git a/src/lxc/utils.c b/src/lxc/utils.c
 index e07ca7b..9794553 100644
 --- a/src/lxc/utils.c
 +++ b/src/lxc/utils.c
 @@ -95,39 +95,25 @@ extern int get_u16(unsigned short *val, const char 
 *arg, int base)
return 0;
   }

 -static int is_all_slashes(char *path)
 -{
 -  while (*path && *path == '/')
 -  path++;
 -  if (*path)
 -  return 0;
 -  return 1;
 -}
 -
   extern int mkdir_p(char *dir, mode_t mode)
   {
 -  int ret;
 -  char *d;
 -
 -  if (is_all_slashes(dir))
 -  return 0;
 -
 -  d = strdup(dir);
 -  if (!d)
 -  return -1;
 -
 -  ret = mkdir_p(dirname(d), mode);
 -  free(d);
 -  if (ret)
 -  return -1;
 -
 -  if (!access(dir, F_OK))
 -  return 0;
 -
 -  if (mkdir(dir, mode)) {
 -  SYSERROR("failed to create directory '%s'\n", dir);
 -  return -1;
 -  }
 +  char *tmp = dir;
 +  char *orig = dir;
 +  char *makeme;
 +
 +  do {
 +  dir = tmp + strspn(tmp, "/");
 +  tmp = dir + strcspn(dir, "/");
 +  makeme = strndupa(orig, dir - orig);
>>>
>>> strndupa *can* fail and return NULL.
>>
>> How?
>
> I was hoping that smart libc on embedded would return NULL if it sees
> there isn't enough space.  I misread the strndupa manpage to say it
> returns NULL on failure - I see there is no such promise.
>
>> strndupa() uses alloca(), which allocates memory on the stack.
>> *If* it fails we have already overrun the stack and are on a one-way trip
>> to lala land. :-)
>>
>>>
 +  if (*makeme) {
 +  if (!access(makeme, F_OK))
 +  return 0;
>>>
>>> did you mean to continue here?
>>
>> No, if the access() we have to stop.
>   =
>
> If the access() does what?  access("/var", F_OK) should immediately
> return 0, so you're saying mkdir_p("/var/lib/lxc/c1") should immediately
> fail?  It's entirely possible I'm not thinking right, but...

Please let me dig into mkdir(1) to copy the exact semantics. :-)

Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

On 04/18/2013 10:34 AM, Stéphane Graber wrote:
> On 04/18/2013 10:32 AM, Stéphane Graber wrote:
>> This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.
>>
>> This commit was preventing container startup on my machine, making them
>> all fail with various "No such file or directory" errors.
>>
>> Signed-off-by: Stéphane Graber 
> 
> Was directly applied to the staging branch as the issue was preventing
> regular use of LXC.

Hmm, with the recent round of moderation on the list, it looks like I
may have applied the wrong version of the patch.

There's two identically named patch on the ML but with different content.
I'll test the second one and see if that solves my issues.

In the future, please include "v2" in the name of the second patch so
that people trying to figure out what to apply to staging don't get
confused ;)


>> ---
>>  src/lxc/utils.c | 48 +++-
>>  1 file changed, 31 insertions(+), 17 deletions(-)
>>
>> diff --git a/src/lxc/utils.c b/src/lxc/utils.c
>> index 9794553..e07ca7b 100644
>> --- a/src/lxc/utils.c
>> +++ b/src/lxc/utils.c
>> @@ -95,25 +95,39 @@ extern int get_u16(unsigned short *val, const char *arg, 
>> int base)
>>  return 0;
>>  }
>>  
>> +static int is_all_slashes(char *path)
>> +{
>> +while (*path && *path == '/')
>> +path++;
>> +if (*path)
>> +return 0;
>> +return 1;
>> +}
>> +
>>  extern int mkdir_p(char *dir, mode_t mode)
>>  {
>> -char *tmp = dir;
>> -char *orig = dir;
>> -char *makeme;
>> -
>> -do {
>> -dir = tmp + strspn(tmp, "/");
>> -tmp = dir + strcspn(dir, "/");
>> -makeme = strndupa(orig, dir - orig);
>> -if (*makeme) {
>> -if (!access(makeme, F_OK))
>> -return 0;
>> -if (mkdir(makeme, mode)) {
>> -SYSERROR("failed to create directory '%s'\n", 
>> makeme);
>> -return -1;
>> -}
>> -}
>> -} while(tmp != dir);
>> +int ret;
>> +char *d;
>> +
>> +if (is_all_slashes(dir))
>> +return 0;
>> +
>> +d = strdup(dir);
>> +if (!d)
>> +return -1;
>> +
>> +ret = mkdir_p(dirname(d), mode);
>> +free(d);
>> +if (ret)
>> +return -1;
>> +
>> +if (!access(dir, F_OK))
>> +return 0;
>> +
>> +if (mkdir(dir, mode)) {
>> +SYSERROR("failed to create directory '%s'\n", dir);
>> +return -1;
>> +}
>>  
>>  return 0;
>>  }
>>
> 
> 
> 
> 
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> 
> 
> 
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 


-- 
Stéphane Graber



-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

On 04/18/2013 10:48 AM, Stéphane Graber wrote:
> On 04/18/2013 10:34 AM, Stéphane Graber wrote:
>> On 04/18/2013 10:32 AM, Stéphane Graber wrote:
>>> This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.
>>>
>>> This commit was preventing container startup on my machine, making them
>>> all fail with various "No such file or directory" errors.
>>>
>>> Signed-off-by: Stéphane Graber 
>>
>> Was directly applied to the staging branch as the issue was preventing
>> regular use of LXC.
> 
> Hmm, with the recent round of moderation on the list, it looks like I
> may have applied the wrong version of the patch.
> 
> There's two identically named patch on the ML but with different content.
> I'll test the second one and see if that solves my issues.
> 
> In the future, please include "v2" in the name of the second patch so
> that people trying to figure out what to apply to staging don't get
> confused ;)

Confirmed, the v2 seems fine here. Pushing that to staging.

> 
>>> ---
>>>  src/lxc/utils.c | 48 +++-
>>>  1 file changed, 31 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/src/lxc/utils.c b/src/lxc/utils.c
>>> index 9794553..e07ca7b 100644
>>> --- a/src/lxc/utils.c
>>> +++ b/src/lxc/utils.c
>>> @@ -95,25 +95,39 @@ extern int get_u16(unsigned short *val, const char 
>>> *arg, int base)
>>> return 0;
>>>  }
>>>  
>>> +static int is_all_slashes(char *path)
>>> +{
>>> +   while (*path && *path == '/')
>>> +   path++;
>>> +   if (*path)
>>> +   return 0;
>>> +   return 1;
>>> +}
>>> +
>>>  extern int mkdir_p(char *dir, mode_t mode)
>>>  {
>>> -   char *tmp = dir;
>>> -   char *orig = dir;
>>> -   char *makeme;
>>> -
>>> -   do {
>>> -   dir = tmp + strspn(tmp, "/");
>>> -   tmp = dir + strcspn(dir, "/");
>>> -   makeme = strndupa(orig, dir - orig);
>>> -   if (*makeme) {
>>> -   if (!access(makeme, F_OK))
>>> -   return 0;
>>> -   if (mkdir(makeme, mode)) {
>>> -   SYSERROR("failed to create directory '%s'\n", 
>>> makeme);
>>> -   return -1;
>>> -   }
>>> -   }
>>> -   } while(tmp != dir);
>>> +   int ret;
>>> +   char *d;
>>> +
>>> +   if (is_all_slashes(dir))
>>> +   return 0;
>>> +
>>> +   d = strdup(dir);
>>> +   if (!d)
>>> +   return -1;
>>> +
>>> +   ret = mkdir_p(dirname(d), mode);
>>> +   free(d);
>>> +   if (ret)
>>> +   return -1;
>>> +
>>> +   if (!access(dir, F_OK))
>>> +   return 0;
>>> +
>>> +   if (mkdir(dir, mode)) {
>>> +   SYSERROR("failed to create directory '%s'\n", dir);
>>> +   return -1;
>>> +   }
>>>  
>>> return 0;
>>>  }
>>>


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

On 04/18/2013 10:34 AM, Stéphane Graber wrote:
> On 04/18/2013 10:32 AM, Stéphane Graber wrote:
>> This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.
>>
>> This commit was preventing container startup on my machine, making them
>> all fail with various "No such file or directory" errors.
>>
>> Signed-off-by: Stéphane Graber 
> 
> Was directly applied to the staging branch as the issue was preventing
> regular use of LXC.

Hmm, with the recent round of moderation on the list, it looks like I
may have applied the wrong version of the patch.

There's two identically named patch on the ML but with different content.
I'll test the second one and see if that solves my issues.

In the future, please include "v2" in the name of the second patch so
that people trying to figure out what to apply to staging don't get
confused ;)


>> ---
>>  src/lxc/utils.c | 48 +++-
>>  1 file changed, 31 insertions(+), 17 deletions(-)
>>
>> diff --git a/src/lxc/utils.c b/src/lxc/utils.c
>> index 9794553..e07ca7b 100644
>> --- a/src/lxc/utils.c
>> +++ b/src/lxc/utils.c
>> @@ -95,25 +95,39 @@ extern int get_u16(unsigned short *val, const char *arg, 
>> int base)
>>  return 0;
>>  }
>>  
>> +static int is_all_slashes(char *path)
>> +{
>> +while (*path && *path == '/')
>> +path++;
>> +if (*path)
>> +return 0;
>> +return 1;
>> +}
>> +
>>  extern int mkdir_p(char *dir, mode_t mode)
>>  {
>> -char *tmp = dir;
>> -char *orig = dir;
>> -char *makeme;
>> -
>> -do {
>> -dir = tmp + strspn(tmp, "/");
>> -tmp = dir + strcspn(dir, "/");
>> -makeme = strndupa(orig, dir - orig);
>> -if (*makeme) {
>> -if (!access(makeme, F_OK))
>> -return 0;
>> -if (mkdir(makeme, mode)) {
>> -SYSERROR("failed to create directory '%s'\n", 
>> makeme);
>> -return -1;
>> -}
>> -}
>> -} while(tmp != dir);
>> +int ret;
>> +char *d;
>> +
>> +if (is_all_slashes(dir))
>> +return 0;
>> +
>> +d = strdup(dir);
>> +if (!d)
>> +return -1;
>> +
>> +ret = mkdir_p(dirname(d), mode);
>> +free(d);
>> +if (ret)
>> +return -1;
>> +
>> +if (!access(dir, F_OK))
>> +return 0;
>> +
>> +if (mkdir(dir, mode)) {
>> +SYSERROR("failed to create directory '%s'\n", dir);
>> +return -1;
>> +}
>>  
>>  return 0;
>>  }
>>
> 
> 
> 
> 
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> 
> 
> 
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 


-- 
Stéphane Graber



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] [PATCH] remove duplicate method declaration (setup_cgroup).

[Kevin Wilson]

This patch removes duplicate method declaration (setup_cgroup)
in conf.h.

Signed-off-by: Kevin Wilson 
---
 src/lxc/conf.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/lxc/conf.h b/src/lxc/conf.h
index 465b1ec..0e87c69 100644
--- a/src/lxc/conf.h
+++ b/src/lxc/conf.h
@@ -313,8 +313,6 @@ extern int lxc_clear_cgroups(struct lxc_conf *c, const char 
*key);
 extern int lxc_clear_mount_entries(struct lxc_conf *c);
 extern int lxc_clear_hooks(struct lxc_conf *c, const char *key);
 
-extern int setup_cgroup(const char *name, struct lxc_list *cgroups);
-
 extern int uid_shift_ttys(int pid, struct lxc_conf *conf);
 
 /*
-- 
1.8.1.4


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] git tree and man pages

[David Shwatrz]

Hi, lxc-developers,
I had performed
git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc
and under doc I don't see any man pages.

for a lxc tar gz I downloaded, they are under doc.

Is there a reason man pages are not in git ?


DS

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] git tree and man pages

[Stéphane Graber]

On 04/18/2013 01:34 PM, David Shwatrz wrote:
> Hi, lxc-developers,
> I had performed
> git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc
> and under doc I don't see any man pages.
> 
> for a lxc tar gz I downloaded, they are under doc.
> 
> Is there a reason man pages are not in git ?
> 
> 
> DS

The manpages are in git, just not in their compiled form.

We had a problem in the past that made some of the tar.gz contain the
compiled form as well as the source but I fixed that for 0.9 so the 0.9
tarball should look pretty much identical to the git tree.

In short, the man pages are the .sgml.in files, anything else is a
compiled file which gets discarded at build time.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] remove duplicate method declaration (setup_cgroup).

[Serge Hallyn]

Quoting Kevin Wilson (wkev...@gmail.com):
> This patch removes duplicate method declaration (setup_cgroup)
> in conf.h.
> 
> Signed-off-by: Kevin Wilson 

Uh.  What the *?  How did I leave that in?

Thanks.

Acked-by: Serge E. Hallyn 

> ---
>  src/lxc/conf.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/src/lxc/conf.h b/src/lxc/conf.h
> index 465b1ec..0e87c69 100644
> --- a/src/lxc/conf.h
> +++ b/src/lxc/conf.h
> @@ -313,8 +313,6 @@ extern int lxc_clear_cgroups(struct lxc_conf *c, const 
> char *key);
>  extern int lxc_clear_mount_entries(struct lxc_conf *c);
>  extern int lxc_clear_hooks(struct lxc_conf *c, const char *key);
>  
> -extern int setup_cgroup(const char *name, struct lxc_list *cgroups);
> -
>  extern int uid_shift_ttys(int pid, struct lxc_conf *conf);
>  
>  /*
> -- 
> 1.8.1.4
> 
> 
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] [RFC PATCH] api_clone: implement basic directory-backed container clone

[Serge Hallyn]

1. commonize waitpid users to use a single helper.  We frequently want
to run something in a clean namespace, or fork off a script.  This
lets us keep the function doing fork:(1)exec(2)waitpid simpler.

2. start a blockdev backend implementation.  This will be used for
mounting, copying, and snapshotting container filesystems.

3. implement lvm, directory, and overlayfs backends.

4. For overlayfs, support a new lxc.rootfs format of
'bdevtype:'.  This means you can now use overlayfs-based
containers without using lxc-start-ephemeral, by using
lxc.rootfs = overlayfs:/readonly-dir:writeable-dir

5. add a set of simple clone testcases

The testcase shows how to use this.  There are two types of clones: copy
and snapshot.  Right now you create a copy clone from lvm->lvm and dir->dir,
a snapshot clone from lvm->lvm, dir->overlayfs and overlayfs->overlayfs.
Note that this means you can now use the api to do incremental image
development, as is done manually by docker:

// create original container, directory based
c1 = lxc_container_new("c1", NULL);
c1->save_config(c1, NULL);
c1->createl(c1, "ubuntu", NULL);
c1->load_config(c1, NULL);

// start it, log in and make some changes
c1->want_daemonize(c1);
c1->startl(c1, 0, NULL, NULL);
// log in and do stuff, shut it down

// create overlayfs clone
c2 = c1->clone(c1, "c2", NULL, LXC_CLONE_SNAPSHOT, "overlayfs",
NULL, 0);
lxc_container_put(c1);
// start it, log in make some changes
c2->want_daemonize(c2);
c2->startl(c2, 0, NULL, NULL);
// log in and do stuff, shut it down

c3 = c2->clone(c2, "c3", NULL, LXC_CLONE_SNAPSHOT, "overlayfs",
NULL, 0);
lxc_container_put(c2);
// etc

c2 mounts c1's rootfs overlayed with /var/lib/lxc/c2/delta0.  When c3 is
created, c2's delta0 is rsync'ed to c3's, and c3 mounts c1's rootfs
overlayed with its rsynced /var/lib/lxc/c3/delta0.

Once Stéphane implements :) python bindings, lxc-clone can be switched
to python using this implementation.

Still to do (there's more, but off top of my head):

1. support btrfs, zfs, aufs
2. have clone handle other mount entries (right now it only clones
the rootfs)
3. bindings
4. re-write lxc-clone
5. add lxc.numsnapshots - in the above case, c1 should not be
destroyable until all its clones are gone
6. Move bdev to its own directory (src/bdev) with one backing store
per file
7. Consider using fewer execs (for lvcreate etc)

Signed-off-by: Serge Hallyn 
---
 src/lxc/Makefile.am|   2 +
 src/lxc/bdev.c | 945 +
 src/lxc/bdev.h |  50 +++
 src/lxc/conf.c |  11 +-
 src/lxc/lxccontainer.c | 551 +---
 src/lxc/lxccontainer.h |  38 ++
 src/lxc/utils.c|  20 ++
 src/lxc/utils.h|   5 +
 src/tests/Makefile.am  |   4 +-
 src/tests/clonetest.c  | 178 ++
 10 files changed, 1756 insertions(+), 48 deletions(-)
 create mode 100644 src/lxc/bdev.c
 create mode 100644 src/lxc/bdev.h
 create mode 100644 src/tests/clonetest.c

diff --git a/src/lxc/Makefile.am b/src/lxc/Makefile.am
index ebeca466..cc2f163 100644
--- a/src/lxc/Makefile.am
+++ b/src/lxc/Makefile.am
@@ -16,6 +16,7 @@ pkginclude_HEADERS = \
attach.h \
lxccontainer.h \
lxclock.h \
+   bdev.h \
version.h
 
 if IS_BIONIC
@@ -36,6 +37,7 @@ so_PROGRAMS = liblxc.so
 
 liblxc_so_SOURCES = \
arguments.c arguments.h \
+   bdev.c bdev.h \
commands.c commands.h \
start.c start.h \
stop.c \
diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
new file mode 100644
index 000..7f109af
--- /dev/null
+++ b/src/lxc/bdev.c
@@ -0,0 +1,945 @@
+/*
+ * 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
+ */
+
+/*
+ * this is all just a first shot for experiment.  If we go this route, much
+ * shoudl change.  bdev should be a directory with per-bdev file.  Things which
+ * I'm doing by calling out to userspace should sometimes be done through
+ * libraries like liblvm2
+ */
+#define _GNU_S

Re: [lxc-devel] git tree and man pages

[David Shwatrz]

Hello,
Thanks for the answer.

Is there a way to generate the man pages after downloaded the
git tree?  When I ran "make" the man pages were not generated.

regards,
David


On Thu, Apr 18, 2013 at 2:45 PM, Stéphane Graber  wrote:
> On 04/18/2013 01:34 PM, David Shwatrz wrote:
>> Hi, lxc-developers,
>> I had performed
>> git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc
>> and under doc I don't see any man pages.
>>
>> for a lxc tar gz I downloaded, they are under doc.
>>
>> Is there a reason man pages are not in git ?
>>
>>
>> DS
>
> The manpages are in git, just not in their compiled form.
>
> We had a problem in the past that made some of the tar.gz contain the
> compiled form as well as the source but I fixed that for 0.9 so the 0.9
> tarball should look pretty much identical to the git tree.
>
> In short, the man pages are the .sgml.in files, anything else is a
> compiled file which gets discarded at build time.
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] git tree and man pages

[Stéphane Graber]

On 04/18/2013 05:13 PM, David Shwatrz wrote:
> Hello,
> Thanks for the answer.
> 
> Is there a way to generate the man pages after downloaded the
> git tree?  When I ran "make" the man pages were not generated.
> 
> regards,
> David

You need to pass --enable-doc to the configure script.

> 
> On Thu, Apr 18, 2013 at 2:45 PM, Stéphane Graber  wrote:
>> On 04/18/2013 01:34 PM, David Shwatrz wrote:
>>> Hi, lxc-developers,
>>> I had performed
>>> git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc
>>> and under doc I don't see any man pages.
>>>
>>> for a lxc tar gz I downloaded, they are under doc.
>>>
>>> Is there a reason man pages are not in git ?
>>>
>>>
>>> DS
>>
>> The manpages are in git, just not in their compiled form.
>>
>> We had a problem in the past that made some of the tar.gz contain the
>> compiled form as well as the source but I fixed that for 0.9 so the 0.9
>> tarball should look pretty much identical to the git tree.
>>
>> In short, the man pages are the .sgml.in files, anything else is a
>> compiled file which gets discarded at build time.
>>
>> --
>> Stéphane Graber
>> Ubuntu developer
>> http://www.ubuntu.com
>>
>>
>> --
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> ___
>> 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: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] python: Lots of fixes in C extension

[Serge Hallyn]

Quoting Stéphane Graber (stgra...@ubuntu.com):
> Fixes a lot of issues found by a code review done by Barry Warsaw.
> 
> Those include:
>  - Wrong signature for getters
>  - Various memory leaks
>  - Various optimizations
>  - More consistent return values
>  - Proper exception handling
> 
> Reported-by: Barry Warsaw 
> Signed-off-by: Stéphane Graber 

Much of this (like PyTuple_GET_SIZE) I have no idea on, but overall looks
good, and of course I'll trust Barry's advice :)

Acked-by: Serge E. Hallyn 

> ---
>  src/python-lxc/lxc.c | 270 
> +++
>  1 file changed, 184 insertions(+), 86 deletions(-)
> 
> diff --git a/src/python-lxc/lxc.c b/src/python-lxc/lxc.c
> index 8da6f36..85bab11 100644
> --- a/src/python-lxc/lxc.c
> +++ b/src/python-lxc/lxc.c
> @@ -34,13 +34,19 @@ typedef struct {
>  
>  char**
>  convert_tuple_to_char_pointer_array(PyObject *argv) {
> -int argc = PyTuple_Size(argv);
> +int argc = PyTuple_GET_SIZE(argv);
>  int i;
>  
>  char **result = (char**) malloc(sizeof(char*)*argc + 1);
>  
> +if (result == NULL) {
> +PyErr_SetNone(PyExc_MemoryError);
> +return NULL;
> +}
> +
>  for (i = 0; i < argc; i++) {
> -PyObject *pyobj = PyTuple_GetItem(argv, i);
> +PyObject *pyobj = PyTuple_GET_ITEM(argv, i);
> +assert(pyobj != NULL);
>  
>  char *str = NULL;
>  PyObject *pystr = NULL;
> @@ -51,8 +57,17 @@ convert_tuple_to_char_pointer_array(PyObject *argv) {
>  }
>  
>  pystr = PyUnicode_AsUTF8String(pyobj);
> +if (pystr == NULL) {
> +PyErr_SetString(PyExc_ValueError, "Unable to convert to UTF-8");
> +free(result);
> +return NULL;
> +}
> +
>  str = PyBytes_AsString(pystr);
> +assert(str != NULL);
> +
>  memcpy((char *) &result[i], (char *) &str, sizeof(str));
> +Py_DECREF(pystr);
>  }
>  
>  result[argc] = NULL;
> @@ -82,18 +97,27 @@ Container_init(Container *self, PyObject *args, PyObject 
> *kwds)
>  {
>  static char *kwlist[] = {"name", "config_path", NULL};
>  char *name = NULL;
> +PyObject *fs_config_path = NULL;
>  char *config_path = NULL;
>  
> -if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|s", kwlist,
> -  &name, &config_path))
> +if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|O&", kwlist,
> +  &name,
> +  PyUnicode_FSConverter, 
> &fs_config_path))
>  return -1;
>  
> +if (fs_config_path != NULL) {
> +config_path = PyBytes_AS_STRING(fs_config_path);
> +assert(config_path != NULL);
> +}
> +
>  self->container = lxc_container_new(name, config_path);
>  if (!self->container) {
> -fprintf(stderr, "%d: error creating lxc_container %s\n", __LINE__, 
> name);
> +Py_XDECREF(fs_config_path);
> +fprintf(stderr, "%d: error creating container %s\n", __LINE__, name);
>  return -1;
>  }
>  
> +Py_XDECREF(fs_config_path);
>  return 0;
>  }
>  
> @@ -111,13 +135,14 @@ LXC_get_version(PyObject *self, PyObject *args)
>  
>  // Container properties
>  static PyObject *
> -Container_config_file_name(Container *self, PyObject *args, PyObject *kwds)
> +Container_config_file_name(Container *self, void *closure)
>  {
> -return 
> PyUnicode_FromString(self->container->config_file_name(self->container));
> +return PyUnicode_FromString(
> +self->container->config_file_name(self->container));
>  }
>  
>  static PyObject *
> -Container_defined(Container *self, PyObject *args, PyObject *kwds)
> +Container_defined(Container *self, void *closure)
>  {
>  if (self->container->is_defined(self->container)) {
>  Py_RETURN_TRUE;
> @@ -127,19 +152,19 @@ Container_defined(Container *self, PyObject *args, 
> PyObject *kwds)
>  }
>  
>  static PyObject *
> -Container_init_pid(Container *self, PyObject *args, PyObject *kwds)
> +Container_init_pid(Container *self, void *closure)
>  {
> -return Py_BuildValue("i", self->container->init_pid(self->container));
> +return PyLong_FromLong(self->container->init_pid(self->container));
>  }
>  
>  static PyObject *
> -Container_name(Container *self, PyObject *args, PyObject *kwds)
> +Container_name(Container *self, void *closure)
>  {
>  return PyUnicode_FromString(self->container->name);
>  }
>  
>  static PyObject *
> -Container_running(Container *self, PyObject *args, PyObject *kwds)
> +Container_running(Container *self, void *closure)
>  {
>  if (self->container->is_running(self->container)) {
>  Py_RETURN_TRUE;
> @@ -149,7 +174,7 @@ Container_running(Container *self, PyObject *args, 
> PyObject *kwds)
>  }
>  
>  static PyObject *
> -Container_state(Container *self, PyObject *args, PyObject *kwds)
> +Container_state(Container *self, void *closure)
>  {
>  return PyUnicode_FromSt

Re: [lxc-devel] git tree and man pages

[David Shwatrz]

Hi,
Great.
After "yum install docbook2X" and
./configure --enable-doc” it worked.

rgs
DS

On Thu, Apr 18, 2013 at 6:31 PM, Stéphane Graber  wrote:
> On 04/18/2013 05:13 PM, David Shwatrz wrote:
>> Hello,
>> Thanks for the answer.
>>
>> Is there a way to generate the man pages after downloaded the
>> git tree?  When I ran "make" the man pages were not generated.
>>
>> regards,
>> David
>
> You need to pass --enable-doc to the configure script.
>
>>
>> On Thu, Apr 18, 2013 at 2:45 PM, Stéphane Graber  wrote:
>>> On 04/18/2013 01:34 PM, David Shwatrz wrote:
 Hi, lxc-developers,
 I had performed
 git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc
 and under doc I don't see any man pages.

 for a lxc tar gz I downloaded, they are under doc.

 Is there a reason man pages are not in git ?


 DS
>>>
>>> The manpages are in git, just not in their compiled form.
>>>
>>> We had a problem in the past that made some of the tar.gz contain the
>>> compiled form as well as the source but I fixed that for 0.9 so the 0.9
>>> tarball should look pretty much identical to the git tree.
>>>
>>> In short, the man pages are the .sgml.in files, anything else is a
>>> compiled file which gets discarded at build time.
>>>
>>> --
>>> Stéphane Graber
>>> Ubuntu developer
>>> http://www.ubuntu.com
>>>
>>>
>>> --
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>> ___
>>> 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
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[richard -rw- weinberger]

On Thu, Apr 18, 2013 at 10:48 AM, Stéphane Graber  wrote:
> On 04/18/2013 10:34 AM, Stéphane Graber wrote:
>> On 04/18/2013 10:32 AM, Stéphane Graber wrote:
>>> This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.
>>>
>>> This commit was preventing container startup on my machine, making them
>>> all fail with various "No such file or directory" errors.
>>>
>>> Signed-off-by: Stéphane Graber 
>>
>> Was directly applied to the staging branch as the issue was preventing
>> regular use of LXC.
>
> Hmm, with the recent round of moderation on the list, it looks like I
> may have applied the wrong version of the patch.
>
> There's two identically named patch on the ML but with different content.
> I'll test the second one and see if that solves my issues.
>
> In the future, please include "v2" in the name of the second patch so
> that people trying to figure out what to apply to staging don't get
> confused ;)

1. Why have you even applied the first version of my patch?
It looks like you applied while it was under review.
2. Where did Serge's Ack came from? He did never Ack my first patch.
3. If you encounter problems with one of my patches the lest thing you
can do is CC'ing me.

--
Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[richard -rw- weinberger]

On Thu, Apr 18, 2013 at 10:32 AM, Stéphane Graber  wrote:
> This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.
>
> This commit was preventing startup of containers using lxc hooks and
> shutdown of all other containers, requiring the use of a good old
> kill -9 to get rid of lxc-start after a container shutdown.

Please more details.
What exactly does not work?

And why the hell didn't you CC me?

--
Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[S . Çağlar Onur]

Hi Richard,

That happened to me yesterday. I think you can easily reproduce the issue
by just starting a container, logging into it and calling poweroff. You
will see that it will stuck at the end of it. Alternatively you can use
python/c/go api to do the same which shows the same effect.

Best,


On Thu, Apr 18, 2013 at 1:36 PM, richard -rw- weinberger <
richard.weinber...@gmail.com> wrote:

> On Thu, Apr 18, 2013 at 10:32 AM, Stéphane Graber 
> wrote:
> > This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.
> >
> > This commit was preventing startup of containers using lxc hooks and
> > shutdown of all other containers, requiring the use of a good old
> > kill -9 to get rid of lxc-start after a container shutdown.
>
> Please more details.
> What exactly does not work?
>
> And why the hell didn't you CC me?
>
> --
> Thanks,
> //richard
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>



-- 
S.Çağlar Onur 
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[Stéphane Graber]

On 04/18/2013 07:14 PM, richard -rw- weinberger wrote:
> On Thu, Apr 18, 2013 at 10:48 AM, Stéphane Graber  wrote:
>> On 04/18/2013 10:34 AM, Stéphane Graber wrote:
>>> On 04/18/2013 10:32 AM, Stéphane Graber wrote:
 This reverts commit 8de4140644f01180f2fdab55b0ab0f13d1c761c6.

 This commit was preventing container startup on my machine, making them
 all fail with various "No such file or directory" errors.

 Signed-off-by: Stéphane Graber 
>>>
>>> Was directly applied to the staging branch as the issue was preventing
>>> regular use of LXC.
>>
>> Hmm, with the recent round of moderation on the list, it looks like I
>> may have applied the wrong version of the patch.
>>
>> There's two identically named patch on the ML but with different content.
>> I'll test the second one and see if that solves my issues.
>>
>> In the future, please include "v2" in the name of the second patch so
>> that people trying to figure out what to apply to staging don't get
>> confused ;)
> 
> 1. Why have you even applied the first version of my patch?

Because I saw an Ack for a patch with a title that exactly matched one I
had in my history.

> It looks like you applied while it was under review.

No, I applied it after Serge's ack.

> 2. Where did Serge's Ack came from? He did never Ack my first patch.

He only acked the second patch which made it extremely late to the
mailing-list (Serge got it early as he was directly CCed on it).

> 3. If you encounter problems with one of my patches the lest thing you
> can do is CC'ing me.

We don't have any real policy that I know of for this mailing-list so I
go with the one that's the least annoying for everyone involved which is
to always send to the mailing-list and to nobody else (unless someone is
clearly not subscribed to it). That way everyone receives the e-mail at
the same time.

Keep in mind that CCing people is what caused that mess to start with
(that and you not marking the second submit as "v2" which would have
made it trivial to detect).


> --
> Thanks,
> //richard
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

[lxc-devel] [RFC PATCH] allow multiple monitor clients

[Dwight Engen]

After the recent discussions on the lxc monitor, I took a closer look at
it. It seems like Serge was resigned to having some sort of daemon as
having multicast unix domain supported by the kernel is not going to
happen any time soon, and doing it over loopback has some
complications too.

Initially I thought it would be nice to just have lxc-start "be the
daemon" as Stéphane had suggested. I tried this out, putting the fds
for the consumer clients (lxc-monitors) in lxc_mainloop , but this is
problematic for the scenario where lxc-monitor runs first and we miss
some startup states.

So here is what I'm proposing: when lxc-monitor starts, it attempts to
start lxc-monitord. lxc-monitord creates a fifo and a socket on lxcpath.

Producers (containers) wishing to send messages open the fifo and
write their lxc_msg's on it. The reason I used a fifo is so that we get
permission checks on the opening of it. Right now it is created 0600.
This fixes the problem we have today where anyone can open the unix
socket and send state changes in.

Consumers (lxc-monitor) connect to the unix socket and each gets a copy
of the messages. lxc-monitord can do a PEERCRED to ensure the client
should be able to get these messages, this is one benefit to using unix
domain. I don't think it would be difficult to write a lxc-monitor
like client that would bridge the messages onto d-bus.

When lxc-monitord hasn't had a client for 30 seconds it will exit.

Attached is a proof of concept patch for your comments. It works for
the common cases that I've tried but I know it needs some cleanup and
testing if we like the approach. The monitor.c part is hard to read
because that file is mostly rewritten.

I need to test S.Çağlar Onur's scenario of parallel startup with his
test script. We need to decide if we want to monitor per lxcpath or per
container, today it is per path and I think that being able to do
lxc-monitor * would be very useful.

--

Signed-off-by: Dwight Engen 
---
 src/lxc/Makefile.am|   2 +
 src/lxc/af_unix.c  |   5 +-
 src/lxc/lxc_monitor.c  |   2 +
 src/lxc/lxc_monitord.c | 334 +
 src/lxc/mainloop.c |  11 +-
 src/lxc/mainloop.h |   7 ++
 src/lxc/monitor.c  | 180 --
 src/lxc/monitor.h  |  11 +-
 src/lxc/start.c|   7 +-
 9 files changed, 484 insertions(+), 75 deletions(-)
 create mode 100644 src/lxc/lxc_monitord.c

diff --git a/src/lxc/Makefile.am b/src/lxc/Makefile.am
index ebeca466..1fa0fa8 100644
--- a/src/lxc/Makefile.am
+++ b/src/lxc/Makefile.am
@@ -150,6 +150,7 @@ bin_PROGRAMS = \
lxc-start \
lxc-execute \
lxc-monitor \
+   lxc-monitord \
lxc-wait \
lxc-console \
lxc-freeze \
@@ -181,6 +182,7 @@ lxc_freeze_SOURCES = lxc_freeze.c
 lxc_info_SOURCES = lxc_info.c
 lxc_init_SOURCES = lxc_init.c
 lxc_monitor_SOURCES = lxc_monitor.c
+lxc_monitord_SOURCES = lxc_monitord.c
 lxc_restart_SOURCES = lxc_restart.c
 lxc_start_SOURCES = lxc_start.c
 lxc_stop_SOURCES = lxc_stop.c
diff --git a/src/lxc/af_unix.c b/src/lxc/af_unix.c
index eff13d4..ceef340 100644
--- a/src/lxc/af_unix.c
+++ b/src/lxc/af_unix.c
@@ -52,6 +52,7 @@ int lxc_af_unix_open(const char *path, int type, int flags)
 
addr.sun_family = AF_UNIX;
/* copy entire buffer in case of abstract socket */
+   /* FIXME: this is unsafe if path is too long... */
memcpy(addr.sun_path, path,
   path[0]?strlen(path):sizeof(addr.sun_path));
 
@@ -61,7 +62,7 @@ int lxc_af_unix_open(const char *path, int type, int flags)
errno = tmp;
return -1;
}
-   
+
if (type == SOCK_STREAM && listen(fd, 100)) {
int tmp = errno;
close(fd);
@@ -76,7 +77,7 @@ int lxc_af_unix_close(int fd)
 {
struct sockaddr_un addr;
socklen_t addrlen = sizeof(addr);
-   
+
if (!getsockname(fd, (struct sockaddr *)&addr, &addrlen) &&
addr.sun_path[0])
unlink(addr.sun_path);
diff --git a/src/lxc/lxc_monitor.c b/src/lxc/lxc_monitor.c
index 8c15869..0ca829f 100644
--- a/src/lxc/lxc_monitor.c
+++ b/src/lxc/lxc_monitor.c
@@ -87,6 +87,8 @@ int main(int argc, char *argv[])
return -1;
}
 
+   lxc_monitord_spawn(my_args.lxcpath);
+
fd = lxc_monitor_open(my_args.lxcpath);
if (fd < 0)
return -1;
diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
new file mode 100644
index 000..3e9c708
--- /dev/null
+++ b/src/lxc/lxc_monitord.c
@@ -0,0 +1,334 @@
+/*
+ * lxc: linux Container library
+ *
+ * Copyright © 2012 Oracle.
+ *
+ * Authors:
+ * Dwight Engen 
+ *
+ * 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 

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[Stéphane Graber]

On 04/18/2013 08:07 PM, S.Çağlar Onur wrote:
> Hi Richard,
> 
> That happened to me yesterday. I think you can easily reproduce the
> issue by just starting a container, logging into it and calling
> poweroff. You will see that it will stuck at the end of it.
> Alternatively you can use python/c/go api to do the same which shows the
> same effect.
> 
> Best,

Correct, just starting the container and shutting it down triggers the
issue, lxc-start will never exit and you'll need to kill it.

My test container didn't have anything special, it was a standard Ubuntu
container running on a standard Ubuntu system.

As I said, I also had a similar problem with a container having a
pre-start hook which caused it not to start at all and that started
working after the revert. Though I'm not entirely sure that this one
wasn't caused by the hook returning non-zero.

> On Thu, Apr 18, 2013 at 1:36 PM, richard -rw- weinberger
> mailto:richard.weinber...@gmail.com>> wrote:
> 
> On Thu, Apr 18, 2013 at 10:32 AM, Stéphane Graber
> mailto:stgra...@ubuntu.com>> wrote:
> > This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.
> >
> > This commit was preventing startup of containers using lxc hooks and
> > shutdown of all other containers, requiring the use of a good old
> > kill -9 to get rid of lxc-start after a container shutdown.
> 
> Please more details.
> What exactly does not work?
> 
> And why the hell didn't you CC me?
> 
> --
> Thanks,
> //richard
> 
> 
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for
> building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 
> 
> 
> 
> -- 
> S.Çağlar Onur mailto:cag...@10ur.org>>


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com



signature.asc
Description: OpenPGP digital signature
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[richard -rw- weinberger]

On Thu, Apr 18, 2013 at 8:07 PM, S.Çağlar Onur  wrote:
> Hi Richard,
>
> That happened to me yesterday. I think you can easily reproduce the issue by
> just starting a container, logging into it and calling poweroff. You will
> see that it will stuck at the end of it. Alternatively you can use
> python/c/go api to do the same which shows the same effect.

Yeah, in the meanwhile I reproduced the problem and have a partial fix.


--
Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [RFC PATCH] allow multiple monitor clients

[Dwight Engen]

On Thu, 18 Apr 2013 14:22:08 -0400
S.Çağlar Onur  wrote:

> Hey Dwight,
> 
> This sounds great, I'll give it a try ASAP. In the meantime ,if you
> want to test it yourself, you can grab go bindings from github via
> "go get github.com/caglar10ur/lxc" but please keep in your mind that
> you need my other two patches to start/stop work reliably [1]/[2].
> https://github.com/caglar10ur/lxc/tree/master/examples directory
> contains concurrent versions of create/start/stop/shutdown to test.
> 
> [1]
> https://github.com/caglar10ur/lxc-upstream/commit/db60b9c38083e8ed553f3cbdd96ad410bd5eb7ed.patch
> [2]
> https://github.com/caglar10ur/lxc-upstream/commit/97d4daf4cc5016bcb01c72e5cf9fe3189e9df4f5.patch
> 
> Cheers,
 
Thanks Caglar, I may give them a try as I've just built go the other
day to try out docker.

> On Thu, Apr 18, 2013 at 2:09 PM, Dwight Engen
> wrote:
> 
> > After the recent discussions on the lxc monitor, I took a closer
> > look at it. It seems like Serge was resigned to having some sort of
> > daemon as having multicast unix domain supported by the kernel is
> > not going to happen any time soon, and doing it over loopback has
> > some complications too.
> >
> > Initially I thought it would be nice to just have lxc-start "be the
> > daemon" as Stéphane had suggested. I tried this out, putting the fds
> > for the consumer clients (lxc-monitors) in lxc_mainloop , but this
> > is problematic for the scenario where lxc-monitor runs first and we
> > miss some startup states.
> >
> > So here is what I'm proposing: when lxc-monitor starts, it attempts
> > to start lxc-monitord. lxc-monitord creates a fifo and a socket on
> > lxcpath.
> >
> > Producers (containers) wishing to send messages open the fifo and
> > write their lxc_msg's on it. The reason I used a fifo is so that we
> > get permission checks on the opening of it. Right now it is created
> > 0600. This fixes the problem we have today where anyone can open
> > the unix socket and send state changes in.
> >
> > Consumers (lxc-monitor) connect to the unix socket and each gets a
> > copy of the messages. lxc-monitord can do a PEERCRED to ensure the
> > client should be able to get these messages, this is one benefit to
> > using unix domain. I don't think it would be difficult to write a
> > lxc-monitor like client that would bridge the messages onto d-bus.
> >
> > When lxc-monitord hasn't had a client for 30 seconds it will exit.
> >
> > Attached is a proof of concept patch for your comments. It works for
> > the common cases that I've tried but I know it needs some cleanup
> > and testing if we like the approach. The monitor.c part is hard to
> > read because that file is mostly rewritten.
> >
> > I need to test S.Çağlar Onur's scenario of parallel startup with his
> > test script. We need to decide if we want to monitor per lxcpath or
> > per container, today it is per path and I think that being able to
> > do lxc-monitor * would be very useful.
> >
> > --
> >
> > Signed-off-by: Dwight Engen 
> > ---
> >  src/lxc/Makefile.am|   2 +
> >  src/lxc/af_unix.c  |   5 +-
> >  src/lxc/lxc_monitor.c  |   2 +
> >  src/lxc/lxc_monitord.c | 334
> > +
> >  src/lxc/mainloop.c |  11 +-
> >  src/lxc/mainloop.h |   7 ++
> >  src/lxc/monitor.c  | 180 --
> >  src/lxc/monitor.h  |  11 +-
> >  src/lxc/start.c|   7 +-
> >  9 files changed, 484 insertions(+), 75 deletions(-)
> >  create mode 100644 src/lxc/lxc_monitord.c
> >
> > diff --git a/src/lxc/Makefile.am b/src/lxc/Makefile.am
> > index ebeca466..1fa0fa8 100644
> > --- a/src/lxc/Makefile.am
> > +++ b/src/lxc/Makefile.am
> > @@ -150,6 +150,7 @@ bin_PROGRAMS = \
> > lxc-start \
> > lxc-execute \
> > lxc-monitor \
> > +   lxc-monitord \
> > lxc-wait \
> > lxc-console \
> > lxc-freeze \
> > @@ -181,6 +182,7 @@ lxc_freeze_SOURCES = lxc_freeze.c
> >  lxc_info_SOURCES = lxc_info.c
> >  lxc_init_SOURCES = lxc_init.c
> >  lxc_monitor_SOURCES = lxc_monitor.c
> > +lxc_monitord_SOURCES = lxc_monitord.c
> >  lxc_restart_SOURCES = lxc_restart.c
> >  lxc_start_SOURCES = lxc_start.c
> >  lxc_stop_SOURCES = lxc_stop.c
> > diff --git a/src/lxc/af_unix.c b/src/lxc/af_unix.c
> > index eff13d4..ceef340 100644
> > --- a/src/lxc/af_unix.c
> > +++ b/src/lxc/af_unix.c
> > @@ -52,6 +52,7 @@ int lxc_af_unix_open(const char *path, int type,
> > int flags)
> >
> > addr.sun_family = AF_UNIX;
> > /* copy entire buffer in case of abstract socket */
> > +   /* FIXME: this is unsafe if path is too long... */
> > memcpy(addr.sun_path, path,
> >path[0]?strlen(path):sizeof(addr.sun_path));
> >
> > @@ -61,7 +62,7 @@ int lxc_af_unix_open(const char *path, int type,
> > int flags)
> > errno = tmp;
> > return -1;
> > }
> > -
> > +
> > if (type == SOCK_STREAM && listen(fd, 100)) {
> > int tmp =

Re: [lxc-devel] [RFC PATCH] allow multiple monitor clients

[Serge Hallyn]

Quoting Dwight Engen (dwight.en...@oracle.com):
> After the recent discussions on the lxc monitor, I took a closer look at
> it. It seems like Serge was resigned to having some sort of daemon as
> having multicast unix domain supported by the kernel is not going to
> happen any time soon, and doing it over loopback has some
> complications too.
> 
> Initially I thought it would be nice to just have lxc-start "be the
> daemon" as Stéphane had suggested. I tried this out, putting the fds
> for the consumer clients (lxc-monitors) in lxc_mainloop , but this is
> problematic for the scenario where lxc-monitor runs first and we miss
> some startup states.
> 
> So here is what I'm proposing: when lxc-monitor starts, it attempts to
> start lxc-monitord. lxc-monitord creates a fifo and a socket on lxcpath.

Thanks, Dwight.  Looks awesome.  Some comments below, but I'm only
not adding an ack bc you say you want to make some changes first
anyway.

When you send the next version I'll run it through my testsuite (and
presumably ack).

> Producers (containers) wishing to send messages open the fifo and
> write their lxc_msg's on it. The reason I used a fifo is so that we get
> permission checks on the opening of it. Right now it is created 0600.
> This fixes the problem we have today where anyone can open the unix
> socket and send state changes in.
> 
> Consumers (lxc-monitor) connect to the unix socket and each gets a copy
> of the messages. lxc-monitord can do a PEERCRED to ensure the client
> should be able to get these messages, this is one benefit to using unix
> domain. I don't think it would be difficult to write a lxc-monitor
> like client that would bridge the messages onto d-bus.
> 
> When lxc-monitord hasn't had a client for 30 seconds it will exit.
> 
> Attached is a proof of concept patch for your comments. It works for
> the common cases that I've tried but I know it needs some cleanup and
> testing if we like the approach. The monitor.c part is hard to read
> because that file is mostly rewritten.
> 
> I need to test S.Çağlar Onur's scenario of parallel startup with his
> test script. We need to decide if we want to monitor per lxcpath or per
> container,

Do you mean 'per lxcpath or per host'?  We definately don't want per
container.

> today it is per path and I think that being able to do
> lxc-monitor * would be very useful.

If by that you mean 'watch all paths', well - I don't think * is
as useful, but certainly 'lxc-monitor /var/lib/lxc /home/serge/lxcbase'
would be nice to do.  But we can do that later with your monitord,
just by watching both sockets, right?

> 
> --
> 
> Signed-off-by: Dwight Engen 
> ---
...
> +static void lxc_monitord_delete(struct lxc_monitor *mon, const char *lxcpath)
> +{
> + int i;
> +
> + lxc_mainloop_del_handler(&mon->descr, mon->listenfd);
> + close(mon->listenfd);

The ordering here might need to change to ensure we don't get any
clients hanging between the two steps.

...

> +/* routines used by monitor subscribers (lxc-monitor) */
> +int lxc_monitor_close(int fd)
>  {
> - struct sockaddr_un addr = { .sun_family = AF_UNIX };
> - char *offset = &addr.sun_path[1];
> - int fd;
> - size_t ret, len;
> + return close(fd);
> +}
>  
> - /*
> -  * addr.sun_path is only 108 bytes.
> -  * should we take a hash of lxcpath?  a subset of it?
> +int lxc_monitor_sock_name(const char *lxcpath, struct sockaddr_un *addr) {
> + size_t len,ret;
> + char *sockname = &addr->sun_path[0]; // 1 for abstract
> +
> + /* addr.sun_path is only 108 bytes.
> +  * should we take a hash of lxcpath?  a subset of it? ftok()? none
> +  * are guaranteed.

guaranteed to what?  The hash should be pretty immune to duplicates, and
does guarantee the length.  The problem with that is simply that we lose
the ability to easily predict (without a tool :) the abstract socket
name and type it by hand.

...
> diff --git a/src/lxc/start.c b/src/lxc/start.c
> index aefccd6..9451fb7 100644
> --- a/src/lxc/start.c
> +++ b/src/lxc/start.c
> @@ -429,6 +429,9 @@ struct lxc_handler *lxc_init(const char *name, struct 
> lxc_conf *conf, const char
>   if (lxc_command_init(name, handler, lxcpath))
>   goto out_free_name;
>  
> + if (lxc_monitord_spawn(lxcpath))
> + goto out_close_maincmd_fd;

Can I ask why you're doing this?  I don't think it's necessary.  Simply
accept that we might send events that get ignored (as we do now).

> +
>   if (lxc_read_seccomp_config(conf) != 0) {
>   ERROR("failed loading seccomp policy");
>   goto out_close_maincmd_fd;
> @@ -437,7 +440,7 @@ struct lxc_handler *lxc_init(const char *name, struct 
> lxc_conf *conf, const char
>   /* 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_name;
> + goto out_close_maincmd

Re: [lxc-devel] [RFC PATCH] allow multiple monitor clients

[Dwight Engen]

On Thu, 18 Apr 2013 13:48:25 -0500
Serge Hallyn  wrote:

> Quoting Dwight Engen (dwight.en...@oracle.com):
> > After the recent discussions on the lxc monitor, I took a closer
> > look at it. It seems like Serge was resigned to having some sort of
> > daemon as having multicast unix domain supported by the kernel is
> > not going to happen any time soon, and doing it over loopback has
> > some complications too.
> > 
> > Initially I thought it would be nice to just have lxc-start "be the
> > daemon" as Stéphane had suggested. I tried this out, putting the fds
> > for the consumer clients (lxc-monitors) in lxc_mainloop , but this
> > is problematic for the scenario where lxc-monitor runs first and we
> > miss some startup states.
> > 
> > So here is what I'm proposing: when lxc-monitor starts, it attempts
> > to start lxc-monitord. lxc-monitord creates a fifo and a socket on
> > lxcpath.
> 
> Thanks, Dwight.  Looks awesome.  Some comments below, but I'm only
> not adding an ack bc you say you want to make some changes first
> anyway.
> 
> When you send the next version I'll run it through my testsuite (and
> presumably ack).

Oh yeah I'm not ready for a review yet, need to do more testing and fix
those FIXME's, just wanted to get feedback on the approach :) Thanks
for the quick response.

> > Producers (containers) wishing to send messages open the fifo and
> > write their lxc_msg's on it. The reason I used a fifo is so that we
> > get permission checks on the opening of it. Right now it is created
> > 0600. This fixes the problem we have today where anyone can open
> > the unix socket and send state changes in.
> > 
> > Consumers (lxc-monitor) connect to the unix socket and each gets a
> > copy of the messages. lxc-monitord can do a PEERCRED to ensure the
> > client should be able to get these messages, this is one benefit to
> > using unix domain. I don't think it would be difficult to write a
> > lxc-monitor like client that would bridge the messages onto d-bus.
> > 
> > When lxc-monitord hasn't had a client for 30 seconds it will exit.
> > 
> > Attached is a proof of concept patch for your comments. It works for
> > the common cases that I've tried but I know it needs some cleanup
> > and testing if we like the approach. The monitor.c part is hard to
> > read because that file is mostly rewritten.
> > 
> > I need to test S.Çağlar Onur's scenario of parallel startup with his
> > test script. We need to decide if we want to monitor per lxcpath or
> > per container,
> 
> Do you mean 'per lxcpath or per host'?  We definately don't want per
> container.

Right I agree, but I think some of Caglar's patches added the container
name to the path, which would've made it per container. Just verifying
we don't actually want that.
 
> > today it is per path and I think that being able to do
> > lxc-monitor * would be very useful.
> 
> If by that you mean 'watch all paths', well - I don't think * is
> as useful, but certainly
> 'lxc-monitor /var/lib/lxc /home/serge/lxcbase' would be nice to do.
> But we can do that later with your monitord, just by watching both
> sockets, right?

Yep, should be trivial fd wise. For this to work with multiple uids I
guess the check in monitord should be peercred == getuid() || peercred
== 0 that way if you to monitor across uids you have to be root.

> > 
> > --
> > 
> > Signed-off-by: Dwight Engen 
> > ---
> ...
> > +static void lxc_monitord_delete(struct lxc_monitor *mon, const
> > char *lxcpath) +{
> > +   int i;
> > +
> > +   lxc_mainloop_del_handler(&mon->descr, mon->listenfd);
> > +   close(mon->listenfd);
> 
> The ordering here might need to change to ensure we don't get any
> clients hanging between the two steps.

Hmm, good point. Have to think about this, there might be a race the
other way with still having the fd in the epoll set also.
 
> > +/* routines used by monitor subscribers (lxc-monitor) */
> > +int lxc_monitor_close(int fd)
> >  {
> > -   struct sockaddr_un addr = { .sun_family = AF_UNIX };
> > -   char *offset = &addr.sun_path[1];
> > -   int fd;
> > -   size_t ret, len;
> > +   return close(fd);
> > +}
> >  
> > -   /*
> > -* addr.sun_path is only 108 bytes.
> > -* should we take a hash of lxcpath?  a subset of it?
> > +int lxc_monitor_sock_name(const char *lxcpath, struct sockaddr_un
> > *addr) {
> > +   size_t len,ret;
> > +   char *sockname = &addr->sun_path[0]; // 1 for abstract
> > +
> > +   /* addr.sun_path is only 108 bytes.
> > +* should we take a hash of lxcpath?  a subset of it?
> > ftok()? none
> > +* are guaranteed.
> 
> guaranteed to what?  The hash should be pretty immune to duplicates,
> and does guarantee the length.  The problem with that is simply that
> we lose the ability to easily predict (without a tool :) the abstract
> socket name and type it by hand.

Sorry, guaranteed unique. 108 bytes is plenty for a uuid for instance,
but we really don't want collisions. Yeah I think last time this came
up we liked the obviousness of 

Re: [lxc-devel] [RFC PATCH] allow multiple monitor clients

[Dwight Engen]

Thanks Çağlar! I'll look into those things.

On Thu, 18 Apr 2013 15:08:19 -0400
S.Çağlar Onur  wrote:

> Hi,
> 
> I think I got it why, most likely recvfrom gets an EINTR there like
> select.
> 
> int lxc_monitor_read_timeout(int fd, struct lxc_msg *msglxc, int
> timeout) {
> struct sockaddr_un from;
> socklen_t len = sizeof(from);
> int ret;
> 
> ret = recvfrom(fd, msglxc, sizeof(*msglxc), 0,
>(struct sockaddr *)&from, &len);
> if (ret <= 0) {
> SYSERROR("client failed to receive lxc_msg (monitord
> died?)");
> return -1;
> }
> return ret;
> }
> 
> 
> 
> 
> On Thu, Apr 18, 2013 at 3:02 PM, S.Çağlar Onur 
> wrote:
> 
> > Hi Dwight,
> >
> > Couple of quick comments, I needed following to make it compile
> > under ubuntu 12.10 otherwise gcc whines about ignoring return
> > values of those calls.
> >
> > diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
> > index 1d20d67..9d83673 100644
> > --- a/src/lxc/lxc_monitord.c
> > +++ b/src/lxc/lxc_monitord.c
> > @@ -309,7 +309,11 @@ int main(int argc, char *argv[])
> >  }
> >
> > /* sync with parent */
> > -   write(pipefd, "S", 1);
> > +   if (write(pipefd, "S", 1) < 0) {
> > +   ERROR("write failed");
> >  +   goto out;
> > +   }
> > +
> > close(pipefd);
> >
> > if (lxc_monitord_mainloop_add(&mon)) {
> > diff --git a/src/lxc/monitor.c b/src/lxc/monitor.c
> > index 0438fbc..803f98f 100644
> > --- a/src/lxc/monitor.c
> > +++ b/src/lxc/monitor.c
> > @@ -158,6 +158,7 @@ int lxc_monitord_spawn(const char *lxcpath)
> > pid_t pid1,pid2;
> > int pipefd[2];
> > char pipefd_str[10];
> > +   FILE *fd;
> >
> > char * const args[] = {
> > "/usr/bin/lxc-monitord",
> > @@ -188,7 +189,10 @@ int lxc_monitord_spawn(const char *lxcpath)
> > char c;
> > /* wait for daemon to create socket */
> > close(pipefd[1]);
> > -   read(pipefd[0], &c, 1);
> > +   if (read(pipefd[0], &c, 1) < 0) {
> > +   SYSERROR("read failed");
> > +   exit(EXIT_FAILURE);
> > +   }
> > close(pipefd[0]);
> > exit(EXIT_SUCCESS);
> > }
> > @@ -198,9 +202,21 @@ int lxc_monitord_spawn(const char *lxcpath)
> > SYSERROR("failed to setsid");
> > exit(EXIT_FAILURE);
> > }
> > -   freopen("/dev/null", "r", stdin);
> > -   freopen("/dev/null", "w", stdout);
> > -   freopen("/dev/null", "w", stderr);
> >  +   fd = freopen("/dev/null", "r", stdin);
> > +   if (!fd) {
> > +   SYSERROR("freopen failed");
> > +   exit(EXIT_FAILURE);
> > +   }
> > +   fd = freopen("/dev/null", "w", stdout);
> > +   if (!fd) {
> > +   SYSERROR("freopen failed");
> > +   exit(EXIT_FAILURE);
> > +   }
> > +   fd = freopen("/dev/null", "w", stderr);
> > +   if (!fd) {
> > +   SYSERROR("freopen failed");
> > +   exit(EXIT_FAILURE);
> > +   }
> > close(pipefd[0]);
> > sprintf(pipefd_str, "%d", pipefd[1]);
> > execvp(args[0], args);
> >
> > and time to time (I think that only happens if monitord wasn't
> > running initially) I get following while starting 10 containers in
> > parallel
> >
> > [caglar@qgq:~/Project/lxc/examples] sudo ./concurrent_start
> > Starting the container (2)...
> > Starting the container (6)...
> > Starting the container (1)...
> > lxc_container: Invalid argument - client failed to receive lxc_msg
> > (monitord died?)
> > Starting the container (2) failed...
> > Starting the container (0)...
> > Starting the container (3)...
> > Starting the container (5)...
> > Starting the container (7)...
> > Starting the container (8)...
> > Starting the container (9)...
> > Starting the container (4)...
> >
> > Best,
> >
> >
> > On Thu, Apr 18, 2013 at 2:47 PM, Dwight Engen
> > wrote:
> >
> >> On Thu, 18 Apr 2013 14:22:08 -0400
> >> S.Çağlar Onur  wrote:
> >>
> >> > Hey Dwight,
> >> >
> >> > This sounds great, I'll give it a try ASAP. In the meantime ,if
> >> > you want to test it yourself, you can grab go bindings from
> >> > github via "go get github.com/caglar10ur/lxc" but please keep in
> >> > your mind that you need my other two patches to start/stop work
> >> > reliably [1]/[2].
> >> > https://github.com/caglar10ur/lxc/tree/master/examples directory
> >> > contains concurrent versions of create/start/stop/shutdown to
> >> > test.
> >> >
> >> > [1]
> >> >
> >> https://github.com/caglar10ur/lxc-upstream/commit/db60b9c38083e8ed553f3cbdd96ad410bd5eb7ed.patch
> >> > [2]
> >> >
> >> https://github.com/caglar10ur/lxc-upstream/commit/97d4daf4cc5016bcb01c72e5cf9fe3189e9df4f5.patch
> >> >
> >> > Cheers,
> >>
> >> Thanks Caglar, I may give them a try as I've just 

[lxc-devel] [PATCH] python: Various fixes to the python scripts

[Stéphane Graber]

This fixes a few issues uncovered by the recent C module fix.

In lxc-start-ephemeral, the hwaddr code wasn't actually working.
Replace by code that properly iterates through the network interfaces
and sets a new MAC address for each entry.

In the python overlay, catch the newly emitted KeyError when in
set_config_item (or setting any previously unset variable would fail).

Signed-off-by: Stéphane Graber 
---
 src/lxc/lxc-start-ephemeral.in | 4 +++-
 src/python-lxc/lxc/__init__.py | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/lxc/lxc-start-ephemeral.in b/src/lxc/lxc-start-ephemeral.in
index bed86e6..b5cad9a 100644
--- a/src/lxc/lxc-start-ephemeral.in
+++ b/src/lxc/lxc-start-ephemeral.in
@@ -134,7 +134,9 @@ dest = lxc.Container(os.path.basename(dest_path), 
args.lxcpath)
 dest.load_config(orig.config_file_name)
 dest.set_config_item("lxc.utsname", dest.name)
 dest.set_config_item("lxc.rootfs", os.path.join(dest_path, "rootfs"))
-dest.set_config_item("lxc.network.hwaddr", randomMAC())
+for nic in dest.network:
+if hasattr(nic, 'hwaddr'):
+nic.hwaddr = randomMAC()
 
 overlay_dirs = [(orig.get_config_item("lxc.rootfs"), "%s/rootfs/" % dest_path)]
 
diff --git a/src/python-lxc/lxc/__init__.py b/src/python-lxc/lxc/__init__.py
index 118a081..e3ce8eb 100644
--- a/src/python-lxc/lxc/__init__.py
+++ b/src/python-lxc/lxc/__init__.py
@@ -412,7 +412,10 @@ class Container(_lxc.Container):
 Set a config key to a provided value.
 The value can be a list for the keys supporting multiple values.
 """
-old_value = self.get_config_item(key)
+try:
+old_value = self.get_config_item(key)
+except KeyError:
+old_value = None
 
 # Check if it's a list
 def set_key(key, value):
-- 
1.8.1.2


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] python: Various fixes to the python scripts

[Serge Hallyn]

Quoting Stéphane Graber (stgra...@ubuntu.com):
> This fixes a few issues uncovered by the recent C module fix.
> 
> In lxc-start-ephemeral, the hwaddr code wasn't actually working.
> Replace by code that properly iterates through the network interfaces
> and sets a new MAC address for each entry.
> 
> In the python overlay, catch the newly emitted KeyError when in
> set_config_item (or setting any previously unset variable would fail).
> 
> Signed-off-by: Stéphane Graber 

Acked-by: Serge E. Hallyn 

> ---
>  src/lxc/lxc-start-ephemeral.in | 4 +++-
>  src/python-lxc/lxc/__init__.py | 5 -
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/lxc/lxc-start-ephemeral.in b/src/lxc/lxc-start-ephemeral.in
> index bed86e6..b5cad9a 100644
> --- a/src/lxc/lxc-start-ephemeral.in
> +++ b/src/lxc/lxc-start-ephemeral.in
> @@ -134,7 +134,9 @@ dest = lxc.Container(os.path.basename(dest_path), 
> args.lxcpath)
>  dest.load_config(orig.config_file_name)
>  dest.set_config_item("lxc.utsname", dest.name)
>  dest.set_config_item("lxc.rootfs", os.path.join(dest_path, "rootfs"))
> -dest.set_config_item("lxc.network.hwaddr", randomMAC())
> +for nic in dest.network:
> +if hasattr(nic, 'hwaddr'):
> +nic.hwaddr = randomMAC()
>  
>  overlay_dirs = [(orig.get_config_item("lxc.rootfs"), "%s/rootfs/" % 
> dest_path)]
>  
> diff --git a/src/python-lxc/lxc/__init__.py b/src/python-lxc/lxc/__init__.py
> index 118a081..e3ce8eb 100644
> --- a/src/python-lxc/lxc/__init__.py
> +++ b/src/python-lxc/lxc/__init__.py
> @@ -412,7 +412,10 @@ class Container(_lxc.Container):
>  Set a config key to a provided value.
>  The value can be a list for the keys supporting multiple values.
>  """
> -old_value = self.get_config_item(key)
> +try:
> +old_value = self.get_config_item(key)
> +except KeyError:
> +old_value = None
>  
>  # Check if it's a list
>  def set_key(key, value):
> -- 
> 1.8.1.2
> 
> 
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 2/2] Revert "start: Detect early failure of the new child"

[richard -rw- weinberger]

On Thu, Apr 18, 2013 at 8:10 PM, Stéphane Graber  wrote:
> On 04/18/2013 08:07 PM, S.Çağlar Onur wrote:
>> Hi Richard,
>>
>> That happened to me yesterday. I think you can easily reproduce the
>> issue by just starting a container, logging into it and calling
>> poweroff. You will see that it will stuck at the end of it.
>> Alternatively you can use python/c/go api to do the same which shows the
>> same effect.
>>
>> Best,
>
> Correct, just starting the container and shutting it down triggers the
> issue, lxc-start will never exit and you'll need to kill it.
>
> My test container didn't have anything special, it was a standard Ubuntu
> container running on a standard Ubuntu system.
>
> As I said, I also had a similar problem with a container having a
> pre-start hook which caused it not to start at all and that started
> working after the revert. Though I'm not entirely sure that this one
> wasn't caused by the hook returning non-zero.

The problem is that my patch is simply wrong. :)

We need to find a sane way to catch SIGCHLD between
lxc_spawn() and lxc_poll().

My patch installed a SIGCHLD handler but I oversaw that the executed hooks
will also produce a SIGCHLD. And if signal_handler(), installed by lxc_poll()
does not see the final SIGCHLD lxc-init my not exit at all.

The whole issue is much more complex than I thought.
Anyway, I'll sent a patch...

>> On Thu, Apr 18, 2013 at 1:36 PM, richard -rw- weinberger
>> mailto:richard.weinber...@gmail.com>> wrote:
>>
>> On Thu, Apr 18, 2013 at 10:32 AM, Stéphane Graber
>> mailto:stgra...@ubuntu.com>> wrote:
>> > This reverts commit 5a5c35c3a01afec515e688c8366e6f893985518d.
>> >
>> > This commit was preventing startup of containers using lxc hooks and
>> > shutdown of all other containers, requiring the use of a good old
>> > kill -9 to get rid of lxc-start after a container shutdown.
>>
>> Please more details.
>> What exactly does not work?
>>
>> And why the hell didn't you CC me?
>>
>> --
>> Thanks,
>> //richard
>>
>> 
>> --
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for
>> building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> ___
>> Lxc-devel mailing list
>> Lxc-devel@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>>
>>
>>
>>
>> --
>> S.Çağlar Onur mailto:cag...@10ur.org>>
>
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>



--
Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/2] Revert "utils: reimplement/fix mkdir_p()"

[richard -rw- weinberger]

On Thu, Apr 18, 2013 at 8:08 PM, Stéphane Graber  wrote:
> He only acked the second patch which made it extremely late to the
> mailing-list (Serge got it early as he was directly CCed on it).
>
>> 3. If you encounter problems with one of my patches the lest thing you
>> can do is CC'ing me.
>
> We don't have any real policy that I know of for this mailing-list so I
> go with the one that's the least annoying for everyone involved which is
> to always send to the mailing-list and to nobody else (unless someone is
> clearly not subscribed to it). That way everyone receives the e-mail at
> the same time.

Please come up with a sane policy. Otherwise more confusion will happen.

What is the current work flow?
Mails get sent to the mailinglist, they land into https://github.com/lxc/lxc
and later on sourceforge?

> Keep in mind that CCing people is what caused that mess to start with
> (that and you not marking the second submit as "v2" which would have
> made it trivial to detect).

A mailer with proper date and thread-support would also have helped. ;-)
If it helps you maintaining lxc, I can use vX in future.
But please CC me always if you encounter issues caused by one of my patches.
I get a gazillion mail per day, being CC'ed helps a lot to sort the
most important mail out...

>
>> --
>> Thanks,
>> //richard
>>
>
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>



--
Thanks,
//richard

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel