Re: [lxc-devel] [PATCH 2/2] daemon: remove pidfile when daemon container is stopped
On 2014/1/19 8:57, Stéphane Graber wrote:
> On Sat, Jan 18, 2014 at 03:00:00PM +0800, Qiang Huang wrote:
>> This is for bug: https://github.com/lxc/lxc/issues/89
>>
>> When start container with daemon model, the daemon process's
>> father will return back to main in start time, and pidfile
>> is removed then, that's not right.
>> So we store pidfile to lxc_container, and remove it when
>> lxc_container_free.
>
> That one looks wrong to me, removing the pid file on lxc_container_free
> is wrong. We want the pidfile removed when the background lxc-start
> exits, not whenever a random API client flushes the container from
> memory.
>
> With your patch, doing something like:
> - lxc-start -n p1 -d -p /tmp/pid
> - python3
> import lxc
> p1 = lxc.Container("p1")
> p1 = None
I'm sorry I'm not family with python, can you explain how this would
happen in real world? Thanks.
>
> Or the equivalent with any binding, or directly in C, will destroy the
> pid file even though the container is clearly still running.
I thought when the backgroud lxc-start exits, it's time for container
to free, because there are no other place to do lxc_contaier_get to
hold the container from freeing.
I must missed something :( , so waiting for your more details.
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] about LXC's coding style
On 2014/1/20 1:54, Serge Hallyn wrote: > Quoting Qiang Huang (h.huangqi...@huawei.com): >> Hi Serge and Stéphane and list, >> >> I'm sorry but I need to complain about this :( >> >> I saw LXC's CONTRIBUTING file, it says: >> "The coding style follows the Linux kernel coding style" >> >> But after reading code these days, there are too many very-long-line >> codes, especially in cgroup.c, this really cause some inconvenience, >> when reading LXC code, I can't vsplit my vim any more :( > > I think that's overstating it... I do it all the time and I have > tiny cheap low-resolution laptops. > >> I don't know if this is an issue for other guys, can we keep the >> rules for the future reviews? >> >> Thanks and best regards. > > It's something I've had mixed feelings about over the years. I'd > like to enforce it, but the code never really followed that to > begin with and I haven't wanted to have some big patch doing random > code churn to follow that guideline. > > The vsplitting is a minor nuisance, and that effect is mentioned > in the guidelines, but the *main* point of that rule is not for > controlling line length itself. The main point is to de-facto > control condition nesting in functions. So if you have too much > > if (a) > if (b) > if (c) > .. Yes, vspliting is a minor complain, the bad nesting and bad naming and bad format are my real points. I'll try to clean up some of that conditions when I spotted again. > > then you should be considering introducing some well-named helper > functions. I do try to enforce that rule, and patches (small, > targeted, clear) to improve code flow would be welcome. > > -serge > > ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 2/2] Add Japanese lxc-usernsexec(1) and fix typo English lxc-usernsexec(1)
Signed-off-by: KATOH Yasufumi --- configure.ac | 1 + doc/ja/Makefile.am| 1 + doc/ja/lxc-usernsexec.sgml.in | 194 ++ doc/lxc-usernsexec.sgml.in| 2 +- 4 files changed, 197 insertions(+), 1 deletion(-) create mode 100644 doc/ja/lxc-usernsexec.sgml.in diff --git a/configure.ac b/configure.ac index 6c8156b..4179dcf 100644 --- a/configure.ac +++ b/configure.ac @@ -641,6 +641,7 @@ AC_CONFIG_FILES([ doc/ja/lxc-unfreeze.sgml doc/ja/lxc-unshare.sgml doc/ja/lxc-user-nic.sgml + doc/ja/lxc-usernsexec.sgml doc/ja/lxc-version.sgml doc/ja/lxc-wait.sgml diff --git a/doc/ja/Makefile.am b/doc/ja/Makefile.am index 31d6f08..fccc66b 100644 --- a/doc/ja/Makefile.am +++ b/doc/ja/Makefile.am @@ -28,6 +28,7 @@ man_MANS = \ lxc-unfreeze.1 \ lxc-unshare.1 \ lxc-user-nic.1 \ + lxc-usernsexec.1 \ lxc-version.1 \ lxc-wait.1 \ \ diff --git a/doc/ja/lxc-usernsexec.sgml.in b/doc/ja/lxc-usernsexec.sgml.in new file mode 100644 index 000..a3e496b --- /dev/null +++ b/doc/ja/lxc-usernsexec.sgml.in @@ -0,0 +1,194 @@ + + + + +]> + + + + @LXC_GENERATE_DATE@ + + +lxc-usernsexec +1 + + + +lxc-usernsexec + + + + 新しいユーザ名前空間内で root としてタスクを実行する + + + + + + lxc-unshare + -m uid-map + -- command + + + + +説明 + + + + lxc-usernsexec は，新しいユーザ名前空間内で root としてタスクを実行するのに使います． + + + + + + +オプション + + + + + + -m uid-map + + + + +ユーザ名前空間内で使うための uid のマッピング．マッピングは，コロンで分けられた 4 つの値から構成されます． +最初の文字は 'u', 'g', 'b' のどれかで，マッピングが UID, GID, UID と GID の両方のうちのどれに関するものなのかを指定します． +次はユーザ名前空間内の最初の ID を指定します．その次はホスト上での最初の ID を指定します．最後はマッピングされる ID の数を指定します． + + + +複数回のマッピングを指定することも可能です．もしマッピングを指定しない場合，デフォルトでは /etc/subuid, /etc/subgid で許可された全ての範囲の UID, GID が，コンテナ内の 0 から始まる UID, GID にマッピングされます． + + + +lxc-usernsexec は，常に名前空間内の 0 に setuid, setgid しようとしますので，名前空間内の UID 0 は必ずマッピングしなければいけないことに注意してください． + + + + + + + + + + +例 + + +割り当てられた subuid の全てをコンテナ内にマッピングしてシェルを起動するには， + + lxc-usernsexec + +のようにしてください．/bin/sh とは違うシェルを起動する場合， + + lxc-usernsexec -- /bin/bash + +のようにしてください． + + + +あなたの UID が 1000 で，コンテナ内の root を 19 にマッピングする場合で，あなたの所有するファイルをコンテナ内の root に chown したい場合は，以下のように実行します． + + lxc-usernsexec -m b:0:1000:1 -m b:1:19:1 -- /bin/chown 1:1 $file + +これはあなたの UID をユーザ名前空間の root に，19 を uid 1 にマッピングしています． +ユーザ名前空間内の root は，名前空間内の全ての ID に対して特権があるため，ホスト上で単純に chown を使えない場合でも，あなたはファイルのオーナーを変更する事が可能です． + + + + &seealso; + + +Author +Serge Hallyn serge.hal...@ubuntu.com + + + + + diff --git a/doc/lxc-usernsexec.sgml.in b/doc/lxc-usernsexec.sgml.in index dec18b9..88a155c 100644 --- a/doc/lxc-usernsexec.sgml.in +++ b/doc/lxc-usernsexec.sgml.in @@ -79,7 +79,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA The uid map to use in the user namespace. Each map consists of four colon-separate values. First a character 'u', 'g' or 'b' to - specify whether this map perttains to user ids, group ids, or + specify whether this map pertains to user ids, group ids, or both; next the first userid in the user namespace; next the first userid as seen on the host; and finally the number of ids to be mapped. -- 1.8.4.4 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/2] doc: Remove the description of lxc-kill in Japanese lxc-execute(1)
Update for commit 33ddfc2adef00e3571137ef60d20de328e32d299 Signed-off-by: KATOH Yasufumi --- doc/ja/lxc-execute.sgml.in | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/ja/lxc-execute.sgml.in b/doc/ja/lxc-execute.sgml.in index cf89deb..db73b7e 100644 --- a/doc/ja/lxc-execute.sgml.in +++ b/doc/ja/lxc-execute.sgml.in @@ -111,11 +111,8 @@ by KATOH Yasufumi 前述の lxc-init は，受け取ったシグナルを開始したコマンドに送るように設計されています． - なので，lxc-kill (1) が送ったシグナルは，ユーザが指定したコマンド (コンテナ内の pid 2 のプロセス) が受けとります． -- 1.8.4.4 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH RFC] api_start: don't get a container reference for the daemonized case
On 2014/1/20 2:17, Serge Hallyn wrote:
> In the daemonized case we will fork, so the anonymous container memlock
> will not be shared between parent and child.
I'm basically agree with this patch.
And I'm also confused about why we need this lxc_container_get
in the first place. Seems like it only work for multi-threads cases,
not this fork() case, because any writing lxc_container will cause
COW, and father's lxc_container_free won't affect child.
After a bit dig, I found this is the only place where uses
lxc_container_get(there are two more in test code, not necessary), so
maybe we can just remove this api till we really need it?
Or maybe I'm missing something, hope somebody clear me up. :)
>
> Please review.
>
> Signed-off-by: Serge Hallyn
> ---
> src/lxc/lxccontainer.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 0bebdff..0e22ccf 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -583,15 +583,11 @@ static bool lxcapi_start(struct lxc_container *c, int
> useinit, char * const argv
> * while container is running...
> */
> if (daemonize) {
> - if (!lxc_container_get(c))
> - return false;
> lxc_monitord_spawn(c->config_path);
>
> pid_t pid = fork();
> - if (pid < 0) {
> - lxc_container_put(c);
> + if (pid < 0)
> return false;
> - }
> if (pid != 0)
> return wait_on_daemonized_start(c, pid);
>
> @@ -632,12 +628,10 @@ reboot:
> goto reboot;
> }
>
> - if (daemonize) {
> - lxc_container_put(c);
Can we leave this put operation here to free lxc_container? Although this
is not a really memory leak, but for this process, it still have
numthreads = 1 and have no where to minus it.
> + if (daemonize)
> exit (ret == 0 ? true : false);
> - } else {
> + else
> return (ret == 0 ? true : false);
> - }
> }
>
> /*
>
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] lxc-start: fix the container leak when daemonize
On 2014/1/20 1:26, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqi...@huawei.com):
>> When start container with daemon model, we'll have a new daemon
>> process in lxcapi_start, whose c->numthreads is 2, inherited
>> from his father. Even his father return to main(), the
>> lxc_container_put won't affect son's numthreads.
>
> The memlock is only between threads. But the child is fork()ed, so the
> lxc_container_put() of one won't affect the other task.
>
> Now maybe wait_on_daemonized_start() should be doing an
> lxc_container_put()?
>
>> So when daemon stops, he should return to main and do
>> lxc_container_put again, rather than exit and leave the
>> container alone.
>
> I disagree. This means two separate processes will continue at the
> point where lxcapi_start() was called. That sounds like a recipe for
> disaster.
Well, I thought as long as child haven't exec(), he'll still have
the same context as his father, where lxcapi_start() was called
is part of it. So I don't see how disaster that will be.
But yes, I agree with the other patch you sent, maybe better solution,
I'll check that again.
>
>> Signed-off-by: Qiang Huang
>
> I'm basically out this week and may not be thinking about it rightly,
> but I'm going to say
>
> Nacked-by: Serge E. Hallyn
>
> in the hopes that someone with enough time will reconsider.
>
>> ---
>> src/lxc/lxccontainer.c | 8 +++-
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
>> index 0bebdff..ddea0d7 100644
>> --- a/src/lxc/lxccontainer.c
>> +++ b/src/lxc/lxccontainer.c
>> @@ -632,12 +632,10 @@ reboot:
>> goto reboot;
>> }
>>
>> -if (daemonize) {
>> +if (daemonize)
>> lxc_container_put(c);
>> -exit (ret == 0 ? true : false);
>> -} else {
>> -return (ret == 0 ? true : false);
>> -}
>> +
>> +return (ret == 0 ? true : false);
>> }
>>
>> /*
>> --
>> 1.8.3
>>
>
>
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v3)
Return an error if the function is not supposed to be called by an unprivileged
user.
Otherwise those calls fail in the middle of their execution with different
reasons.
changes since v2:
- am_unpriv is now a simple geteuid check,
- API functions are now providing error messages,
- lxc-info, lxc-attach are now checking geteuidi,
- lxc-ls is now calling get_ips only if the container is running
Signed-off-by: S.Çağlar Onur
---
src/lxc/lxc-ls | 16 +--
src/lxc/lxc_attach.c | 5
src/lxc/lxc_info.c | 20 +++--
src/lxc/lxccontainer.c | 78 ++
4 files changed, 98 insertions(+), 21 deletions(-)
diff --git a/src/lxc/lxc-ls b/src/lxc/lxc-ls
index 1ed7da4..68c0b41 100755
--- a/src/lxc/lxc-ls
+++ b/src/lxc/lxc-ls
@@ -264,14 +264,14 @@ for container_name in
lxc.list_containers(config_path=nest_lxcpath):
continue
# FIXME: We should get get_ips working as non-root
-if container.running and (not SUPPORT_SETNS_NET
- or os.geteuid() != 0):
-entry[protocol] = 'UNKNOWN'
-continue
-
-ips = container.get_ips(family=family)
-if ips:
-entry[protocol] = ", ".join(ips)
+if container.running:
+if not SUPPORT_SETNS_NET or os.geteuid() != 0:
+entry[protocol] = 'UNKNOWN'
+continue
+
+ips = container.get_ips(family=family)
+if ips:
+entry[protocol] = ", ".join(ips)
# Append the container
containers.append(entry)
diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
index 6744c05..1159d09 100644
--- a/src/lxc/lxc_attach.c
+++ b/src/lxc/lxc_attach.c
@@ -188,6 +188,11 @@ int main(int argc, char *argv[])
lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT;
lxc_attach_command_t command;
+if (geteuid() != 0) {
+ERROR("lxc-attach is not currently supported with unprivileged
containers");
+return -1;
+}
+
ret = lxc_caps_init();
if (ret)
return ret;
diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
index b515087..0990036 100644
--- a/src/lxc/lxc_info.c
+++ b/src/lxc/lxc_info.c
@@ -310,15 +310,19 @@ static int print_info(const char *name, const char
*lxcpath)
}
if (ips) {
- char **addresses = c->get_ips(c, NULL, NULL, 0);
- if (addresses) {
- char *address;
- i = 0;
- while (addresses[i]) {
- address = addresses[i];
- print_info_msg_str("IP:", address);
- i++;
+ if (geteuid() == 0) {
+ char **addresses = c->get_ips(c, NULL, NULL, 0);
+ if (addresses) {
+ char *address;
+ i = 0;
+ while (addresses[i]) {
+ address = addresses[i];
+ print_info_msg_str("IP:", address);
+ i++;
+ }
}
+ } else {
+ print_info_msg_str("IP:", "UNKNOWN");
}
}
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 0bebdff..368cb46 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -62,8 +62,14 @@
#define MAX_BUFFER 4096
+#define NOT_SUPPORTED_ERROR "the requested function %s is not currently
supported with unprivileged containers"
+
lxc_log_define(lxc_container, lxc);
+inline static bool am_unpriv() {
+ return geteuid() != 0;
+}
+
static bool file_exists(const char *f)
{
struct stat statbuf;
@@ -1489,6 +1495,11 @@ static char** lxcapi_get_interfaces(struct lxc_container
*c)
char **interfaces = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv()) {
+ ERROR(NOT_SUPPORTED_ERROR, __FUNCTION__);
+ goto out;
+ }
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1538,6 +1549,11 @@ static char** lxcapi_get_ips(struct lxc_container *c,
const char* interface, con
char *address = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv()) {
+ ERROR(NOT_SUPPORTED_ERROR, __FUNCTION__);
+ goto out;
+ }
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1818,7 +1834,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
static bool lxcapi_destroy(struct lxc_container *c)
{
struct bdev *r = NULL;
- bool bret = false, am_unpriv;
+ bool bret = false;
int ret;
[lxc-devel] [PATCH RFC] api_start: don't get a container reference for the daemonized case
In the daemonized case we will fork, so the anonymous container memlock
will not be shared between parent and child.
Please review.
Signed-off-by: Serge Hallyn
---
src/lxc/lxccontainer.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 0bebdff..0e22ccf 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -583,15 +583,11 @@ static bool lxcapi_start(struct lxc_container *c, int
useinit, char * const argv
* while container is running...
*/
if (daemonize) {
- if (!lxc_container_get(c))
- return false;
lxc_monitord_spawn(c->config_path);
pid_t pid = fork();
- if (pid < 0) {
- lxc_container_put(c);
+ if (pid < 0)
return false;
- }
if (pid != 0)
return wait_on_daemonized_start(c, pid);
@@ -632,12 +628,10 @@ reboot:
goto reboot;
}
- if (daemonize) {
- lxc_container_put(c);
+ if (daemonize)
exit (ret == 0 ? true : false);
- } else {
+ else
return (ret == 0 ? true : false);
- }
}
/*
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] lxc-start: fix the container leak when daemonize
Quoting Serge Hallyn (serge.hal...@ubuntu.com): > Quoting Qiang Huang (h.huangqi...@huawei.com): > > When start container with daemon model, we'll have a new daemon > > process in lxcapi_start, whose c->numthreads is 2, inherited > > from his father. Even his father return to main(), the > > lxc_container_put won't affect son's numthreads. > > The memlock is only between threads. But the child is fork()ed, so the > lxc_container_put() of one won't affect the other task. > > Now maybe wait_on_daemonized_start() should be doing an > lxc_container_put()? Really I'm not sure why the lxc_container_get() is there in the daemonize case. I *think* we should drop it, but again I'd like more time to think about it (or someone else to reason it through) before sending a patch. I'm surprised given the amount of threaded testing done in the past by our go contingency :) that this has sneaked past. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] about LXC's coding style
Quoting Qiang Huang (h.huangqi...@huawei.com): > Hi Serge and Stéphane and list, > > I'm sorry but I need to complain about this :( > > I saw LXC's CONTRIBUTING file, it says: > "The coding style follows the Linux kernel coding style" > > But after reading code these days, there are too many very-long-line > codes, especially in cgroup.c, this really cause some inconvenience, > when reading LXC code, I can't vsplit my vim any more :( I think that's overstating it... I do it all the time and I have tiny cheap low-resolution laptops. > I don't know if this is an issue for other guys, can we keep the > rules for the future reviews? > > Thanks and best regards. It's something I've had mixed feelings about over the years. I'd like to enforce it, but the code never really followed that to begin with and I haven't wanted to have some big patch doing random code churn to follow that guideline. The vsplitting is a minor nuisance, and that effect is mentioned in the guidelines, but the *main* point of that rule is not for controlling line length itself. The main point is to de-facto control condition nesting in functions. So if you have too much if (a) if (b) if (c) .. then you should be considering introducing some well-named helper functions. I do try to enforce that rule, and patches (small, targeted, clear) to improve code flow would be welcome. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 05e5d7: Revert "lxc-start: fix the container leak when dae...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 05e5d7dc9b911b9f1da125fb554de4611d2d1d9b https://github.com/lxc/lxc/commit/05e5d7dc9b911b9f1da125fb554de4611d2d1d9b Author: Stéphane Graber Date: 2014-01-19 (Sun, 19 Jan 2014) Changed paths: M src/lxc/lxccontainer.c Log Message: --- Revert "lxc-start: fix the container leak when daemonize" This reverts commit c3f0f139e155f53c83e0a81f14094e9d0f40e8e9. Done as Serge Hallyn's request: Nacked-by: Serge E. Hallyn ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] lxc-start: fix the container leak when daemonize
Quoting Qiang Huang (h.huangqi...@huawei.com):
> When start container with daemon model, we'll have a new daemon
> process in lxcapi_start, whose c->numthreads is 2, inherited
> from his father. Even his father return to main(), the
> lxc_container_put won't affect son's numthreads.
The memlock is only between threads. But the child is fork()ed, so the
lxc_container_put() of one won't affect the other task.
Now maybe wait_on_daemonized_start() should be doing an
lxc_container_put()?
> So when daemon stops, he should return to main and do
> lxc_container_put again, rather than exit and leave the
> container alone.
I disagree. This means two separate processes will continue at the
point where lxcapi_start() was called. That sounds like a recipe for
disaster.
> Signed-off-by: Qiang Huang
I'm basically out this week and may not be thinking about it rightly,
but I'm going to say
Nacked-by: Serge E. Hallyn
in the hopes that someone with enough time will reconsider.
> ---
> src/lxc/lxccontainer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 0bebdff..ddea0d7 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -632,12 +632,10 @@ reboot:
> goto reboot;
> }
>
> - if (daemonize) {
> + if (daemonize)
> lxc_container_put(c);
> - exit (ret == 0 ? true : false);
> - } else {
> - return (ret == 0 ? true : false);
> - }
> +
> + return (ret == 0 ? true : false);
> }
>
> /*
> --
> 1.8.3
>
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] ecc357: cgmanager: &existed for remove+create now returns ...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: ecc357ca0834b7e72381bbe1bfba06c2893c614b https://github.com/lxc/lxc/commit/ecc357ca0834b7e72381bbe1bfba06c2893c614b Author: Serge Hallyn Date: 2014-01-19 (Sun, 19 Jan 2014) Changed paths: M src/lxc/cgmanager.c Log Message: --- cgmanager: &existed for remove+create now returns -1 on failure Signed-off-by: Serge Hallyn ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Sending discover loop
how you have configured netwrok for the container? are you running dnsmasq on the host? On Sun, Jan 19, 2014 at 12:02 AM, group PICT MANY wrote: > Hi, > Trying to run lxc-start on ubuntu,getting following error: > *Sending discover is looping* > > > > > > > > > > > *yashu@yashu-pc:~$ sudo lxc-start -n yashuinit started: BusyBox v1.18.5 > (Ubuntu 1:1.18.5-1ubuntu4.1) starting pid 2, tty '': '/etc/init.d/rcS' > udhcpc (v1.18.5) startedSending discover...Sending discover...Sending > discover...Sending discover...Sending discover...Sending discover...Sending > discover..*. > > Using lxc 0.9.0 > > ___ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel > > ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Sending discover loop
Hi, Trying to run lxc-start on ubuntu,getting following error: *Sending discover is looping* *yashu@yashu-pc:~$ sudo lxc-start -n yashuinit started: BusyBox v1.18.5 (Ubuntu 1:1.18.5-1ubuntu4.1)starting pid 2, tty '': '/etc/init.d/rcS' udhcpc (v1.18.5) startedSending discover...Sending discover...Sending discover...Sending discover...Sending discover...Sending discover...Sending discover..*. Using lxc 0.9.0 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
