Re: [lxc-devel] [PATCH 2/3] coverity: fix dereference NULL return value
On Fri, 3 May 2013 16:52:02 -0500
Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > also break once we have found root, no need to search the rest of
> > the mounts
>
> I'm not sure about this. There can be >1 entries for /. Though when
Ahh okay, I didn't realize that, the break should be removed. I guess
if they differ then if any are shared we will consider it shared.
> I do
>
> lxc-unshare -s MOUNT -- /bin/sh
> mount --rbind / /
> mount --make-rshared /
> The first / entry seems to become shared, which I wouldn't have
> expected... But I suspect there's a way to get a later entry
> to be shared.
>
> > Signed-off-by: Dwight Engen
> > ---
> > src/lxc/conf.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> > index 125e8a6..827626f 100644
> > --- a/src/lxc/conf.c
> > +++ b/src/lxc/conf.c
> > @@ -1067,10 +1067,11 @@ int detect_shared_rootfs(void)
> > if (strcmp(p+1, "/") == 0) {
> > // this is '/'. is it shared?
> > p = index(p2+1, ' ');
> > - if (strstr(p, "shared:")) {
> > + if (p && strstr(p, "shared:")) {
> > fclose(f);
> > return 1;
> > }
> > + break;
> > }
> > }
> > fclose(f);
> > --
> > 1.8.1.4
> >
> >
> > --
> > Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool designed for production
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > ___
> > Lxc-devel mailing list
> > Lxc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc_monitord - monitor exiting
Hi Çağlar,
I'm confused by your output, it certainly looks like something isn't
right. Do you have a theory as to why monitord thinks it still has 9
clients?
On Sat, 4 May 2013 00:01:45 -0400
S.Çağlar Onur wrote:
> Hi all,
>
> I think I understand why I'm confused before while chasing another
> bug. This is what I'm seeing right now.
>
> * I patched lxc_monitord.c with following
>
> diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
> index e76af71..59f1e9d 100644
> --- a/src/lxc/lxc_monitord.c
> +++ b/src/lxc/lxc_monitord.c
> @@ -373,6 +373,7 @@ int main(int argc, char *argv[])
> }
>
> if (lxc_monitord_create(&mon)) {
> + NOTICE("create failed");
> goto out;
> }
>
> @@ -398,6 +399,7 @@ int main(int argc, char *argv[])
> NOTICE("no clients for 30 seconds, exiting");
> break;
> }
> + NOTICE("clients %d", mon.clientfds_cnt);
> }
>
> lxc_mainloop_close(&mon.descr);
>
> * I started 10 containers using go bindings
>
> [caglar@qgq:~/Project/lxc/examples] sudo ./concurrent_start
> Starting the container (3)...
> Starting the container (2)...
> Starting the container (4)...
> Starting the container (0)...
> Starting the container (1)...
> Starting the container (8)...
> Starting the container (7)...
> Starting the container (6)...
> Starting the container (5)...
> Starting the container (9)...
>
> * Then started to stop them 1 by 1 using lxc-stop
>
> [caglar@qgq:~/Project/lxc/examples] sudo lxc-stop -n 0
> [caglar@qgq:~/Project/lxc/examples] sudo ./list
> 0 (STOPPED)
> 1 (RUNNING)
> 2 (RUNNING)
> 3 (RUNNING)
> 4 (RUNNING)
> 5 (RUNNING)
> 6 (RUNNING)
> 7 (RUNNING)
> 8 (RUNNING)
> 9 (RUNNING)
I assume you stopped 1-8 here?
> [caglar@qgq:~/Project/lxc/examples] date && sudo ./list
> Fri May 3 23:57:14 EDT 2013
> 0 (STOPPED)
> 1 (STOPPED)
> 2 (STOPPED)
> 3 (STOPPED)
> 4 (STOPPED)
> 5 (STOPPED)
> 6 (STOPPED)
> 7 (STOPPED)
> 8 (STOPPED)
> 9 (RUNNING)
> bleach (STOPPED)
>
> * lxc-monitord is still around after ~10min
Looks like its not going away because it thinks there are 9 clients
still. My guess is somehow its not getting notified of the client
closes (or they're still around?). The following patch should provide a
bit more info in the log:
diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
index e76af71..537a2b3 100644
--- a/src/lxc/lxc_monitord.c
+++ b/src/lxc/lxc_monitord.c
@@ -114,6 +114,7 @@ static int lxc_monitord_fifo_delete(struct lxc_monitor *mon)
static void lxc_monitord_sockfd_remove(struct lxc_monitor *mon, int fd) {
int i;
+ INFO("removing fd %d\n", fd);
if (lxc_mainloop_del_handler(&mon->descr, fd))
CRIT("fd:%d not found in mainloop", fd);
close(fd);
@@ -343,7 +344,7 @@ int main(int argc, char *argv[])
if (ret < 0 || ret >= sizeof(logpath))
return EXIT_FAILURE;
- ret = lxc_log_init(NULL, logpath, "NOTICE", "lxc-monitord", 0, lxcpath);
+ ret = lxc_log_init(NULL, logpath, "INFO", "lxc-monitord", 0, lxcpath);
if (ret)
return ret;
> [caglar@qgq:~/Project/lxc/examples] ps aux |
> grep /usr/bin/lxc-monitord caglar1170 0.0 0.0 13580 940
> pts/3S+ 23:57 0:00 grep --color=auto /usr/bin/lxc-monitord
> root 29997 0.0 0.0 15000 744 ?Ss 23:47 0:00
> /usr/bin/lxc-monitord /var/lib/lxc 5
> [caglar@qgq:~/Project/lxc/examples] date
> Fri May 3 23:57:52 EDT 2013
>
> * And lastly here is what lxc-monitord.log shows
>
> [caglar@qgq:~/Project/lxc(clone)] tail
> -f /var/lib/lxc/lxc-monitord.log lxc-monitord 1367639242.631 NOTICE
> lxc_monitord - monitoring lxcpath /var/lib/lxc
>lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.636 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.639 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.643 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.643 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.651 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.654 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.665 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.678 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.681 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.681 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.682 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.707 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.710 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.710 NOTICE lxc_monitord - create failed
>lxc-monitord 1367639242.722 NOTICE lxc_monitord - create failed
>lxc-monitord 13676392
Re: [lxc-devel] lxc_monitord - monitor exiting
Hi Dwight,
On Sat, May 4, 2013 at 9:16 AM, Dwight Engen wrote:
> Hi Çağlar,
>
> I'm confused by your output, it certainly looks like something isn't
> right. Do you have a theory as to why monitord thinks it still has 9
> clients?
Nope, I don't. I'll try to debug more and also try to reproduce this with
python or c api to rule out go.
> On Sat, 4 May 2013 00:01:45 -0400
> S.Çağlar Onur wrote:
>
> > Hi all,
> >
> > I think I understand why I'm confused before while chasing another
> > bug. This is what I'm seeing right now.
> >
> > * I patched lxc_monitord.c with following
> >
> > diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
> > index e76af71..59f1e9d 100644
> > --- a/src/lxc/lxc_monitord.c
> > +++ b/src/lxc/lxc_monitord.c
> > @@ -373,6 +373,7 @@ int main(int argc, char *argv[])
> > }
> >
> > if (lxc_monitord_create(&mon)) {
> > + NOTICE("create failed");
> > goto out;
> > }
> >
> > @@ -398,6 +399,7 @@ int main(int argc, char *argv[])
> > NOTICE("no clients for 30 seconds, exiting");
> > break;
> > }
> > + NOTICE("clients %d", mon.clientfds_cnt);
> > }
> >
> > lxc_mainloop_close(&mon.descr);
> >
> > * I started 10 containers using go bindings
> >
> > [caglar@qgq:~/Project/lxc/examples] sudo ./concurrent_start
> > Starting the container (3)...
> > Starting the container (2)...
> > Starting the container (4)...
> > Starting the container (0)...
> > Starting the container (1)...
> > Starting the container (8)...
> > Starting the container (7)...
> > Starting the container (6)...
> > Starting the container (5)...
> > Starting the container (9)...
> >
> > * Then started to stop them 1 by 1 using lxc-stop
> >
> > [caglar@qgq:~/Project/lxc/examples] sudo lxc-stop -n 0
> > [caglar@qgq:~/Project/lxc/examples] sudo ./list
> > 0 (STOPPED)
> > 1 (RUNNING)
> > 2 (RUNNING)
> > 3 (RUNNING)
> > 4 (RUNNING)
> > 5 (RUNNING)
> > 6 (RUNNING)
> > 7 (RUNNING)
> > 8 (RUNNING)
> > 9 (RUNNING)
>
> I assume you stopped 1-8 here?
Yes, sorry for pasting the half of the output.
> > [caglar@qgq:~/Project/lxc/examples] date && sudo ./list
> > Fri May 3 23:57:14 EDT 2013
> > 0 (STOPPED)
> > 1 (STOPPED)
> > 2 (STOPPED)
> > 3 (STOPPED)
> > 4 (STOPPED)
> > 5 (STOPPED)
> > 6 (STOPPED)
> > 7 (STOPPED)
> > 8 (STOPPED)
> > 9 (RUNNING)
> > bleach (STOPPED)
> >
> > * lxc-monitord is still around after ~10min
>
> Looks like its not going away because it thinks there are 9 clients
> still. My guess is somehow its not getting notified of the client
> closes (or they're still around?). The following patch should provide a
> bit more info in the log:
>
As long as I see they are not around (I use lxc-stop to stop them).
> diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
> index e76af71..537a2b3 100644
> --- a/src/lxc/lxc_monitord.c
> +++ b/src/lxc/lxc_monitord.c
> @@ -114,6 +114,7 @@ static int lxc_monitord_fifo_delete(struct lxc_monitor
> *mon)
> static void lxc_monitord_sockfd_remove(struct lxc_monitor *mon, int fd) {
> int i;
>
> + INFO("removing fd %d\n", fd);
> if (lxc_mainloop_del_handler(&mon->descr, fd))
> CRIT("fd:%d not found in mainloop", fd);
> close(fd);
> @@ -343,7 +344,7 @@ int main(int argc, char *argv[])
> if (ret < 0 || ret >= sizeof(logpath))
> return EXIT_FAILURE;
>
> - ret = lxc_log_init(NULL, logpath, "NOTICE", "lxc-monitord", 0,
> lxcpath);
> + ret = lxc_log_init(NULL, logpath, "INFO", "lxc-monitord", 0,
> lxcpath);
> if (ret)
> return ret;
>
>
>
> > [caglar@qgq:~/Project/lxc/examples] ps aux |
> > grep /usr/bin/lxc-monitord caglar1170 0.0 0.0 13580 940
> > pts/3S+ 23:57 0:00 grep --color=auto /usr/bin/lxc-monitord
> > root 29997 0.0 0.0 15000 744 ?Ss 23:47 0:00
> > /usr/bin/lxc-monitord /var/lib/lxc 5
> > [caglar@qgq:~/Project/lxc/examples] date
> > Fri May 3 23:57:52 EDT 2013
> >
> > * And lastly here is what lxc-monitord.log shows
> >
> > [caglar@qgq:~/Project/lxc(clone)] tail
> > -f /var/lib/lxc/lxc-monitord.log lxc-monitord 1367639242.631 NOTICE
> > lxc_monitord - monitoring lxcpath /var/lib/lxc
> >lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.636 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.639 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.643 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.643 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.651 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.654 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.665 NOTICE lxc_monitord - create failed
> >lxc-monitord 1367639242.678 NOTICE lxc_monit
Re: [lxc-devel] lxc_monitord - monitor exiting
Hi Dwight,
I run same commands and this time it ended up with 6 clients (output ->
http://10ur.org/monitor.txt). I'll try to reproduce this with c/python.;.
On Sat, May 4, 2013 at 11:15 AM, S.Çağlar Onur wrote:
> Hi Dwight,
>
> On Sat, May 4, 2013 at 9:16 AM, Dwight Engen wrote:
>
>> Hi Çağlar,
>>
>> I'm confused by your output, it certainly looks like something isn't
>> right. Do you have a theory as to why monitord thinks it still has 9
>> clients?
>
>
> Nope, I don't. I'll try to debug more and also try to reproduce this with
> python or c api to rule out go.
>
>
>> On Sat, 4 May 2013 00:01:45 -0400
>> S.Çağlar Onur wrote:
>>
>> > Hi all,
>> >
>> > I think I understand why I'm confused before while chasing another
>> > bug. This is what I'm seeing right now.
>> >
>> > * I patched lxc_monitord.c with following
>> >
>> > diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
>> > index e76af71..59f1e9d 100644
>> > --- a/src/lxc/lxc_monitord.c
>> > +++ b/src/lxc/lxc_monitord.c
>> > @@ -373,6 +373,7 @@ int main(int argc, char *argv[])
>> > }
>> >
>> > if (lxc_monitord_create(&mon)) {
>> > + NOTICE("create failed");
>> > goto out;
>> > }
>> >
>> > @@ -398,6 +399,7 @@ int main(int argc, char *argv[])
>> > NOTICE("no clients for 30 seconds, exiting");
>> > break;
>> > }
>> > + NOTICE("clients %d", mon.clientfds_cnt);
>> > }
>> >
>> > lxc_mainloop_close(&mon.descr);
>> >
>> > * I started 10 containers using go bindings
>> >
>> > [caglar@qgq:~/Project/lxc/examples] sudo ./concurrent_start
>> > Starting the container (3)...
>> > Starting the container (2)...
>> > Starting the container (4)...
>> > Starting the container (0)...
>> > Starting the container (1)...
>> > Starting the container (8)...
>> > Starting the container (7)...
>> > Starting the container (6)...
>> > Starting the container (5)...
>> > Starting the container (9)...
>> >
>> > * Then started to stop them 1 by 1 using lxc-stop
>> >
>> > [caglar@qgq:~/Project/lxc/examples] sudo lxc-stop -n 0
>> > [caglar@qgq:~/Project/lxc/examples] sudo ./list
>> > 0 (STOPPED)
>> > 1 (RUNNING)
>> > 2 (RUNNING)
>> > 3 (RUNNING)
>> > 4 (RUNNING)
>> > 5 (RUNNING)
>> > 6 (RUNNING)
>> > 7 (RUNNING)
>> > 8 (RUNNING)
>> > 9 (RUNNING)
>>
>> I assume you stopped 1-8 here?
>
>
> Yes, sorry for pasting the half of the output.
>
>
>> > [caglar@qgq:~/Project/lxc/examples] date && sudo ./list
>> > Fri May 3 23:57:14 EDT 2013
>> > 0 (STOPPED)
>> > 1 (STOPPED)
>> > 2 (STOPPED)
>> > 3 (STOPPED)
>> > 4 (STOPPED)
>> > 5 (STOPPED)
>> > 6 (STOPPED)
>> > 7 (STOPPED)
>> > 8 (STOPPED)
>> > 9 (RUNNING)
>> > bleach (STOPPED)
>> >
>> > * lxc-monitord is still around after ~10min
>>
>> Looks like its not going away because it thinks there are 9 clients
>> still. My guess is somehow its not getting notified of the client
>> closes (or they're still around?). The following patch should provide a
>> bit more info in the log:
>>
>
> As long as I see they are not around (I use lxc-stop to stop them).
>
>
>> diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
>> index e76af71..537a2b3 100644
>> --- a/src/lxc/lxc_monitord.c
>> +++ b/src/lxc/lxc_monitord.c
>> @@ -114,6 +114,7 @@ static int lxc_monitord_fifo_delete(struct
>> lxc_monitor *mon)
>> static void lxc_monitord_sockfd_remove(struct lxc_monitor *mon, int fd) {
>> int i;
>>
>> + INFO("removing fd %d\n", fd);
>> if (lxc_mainloop_del_handler(&mon->descr, fd))
>> CRIT("fd:%d not found in mainloop", fd);
>> close(fd);
>> @@ -343,7 +344,7 @@ int main(int argc, char *argv[])
>> if (ret < 0 || ret >= sizeof(logpath))
>> return EXIT_FAILURE;
>>
>> - ret = lxc_log_init(NULL, logpath, "NOTICE", "lxc-monitord", 0,
>> lxcpath);
>> + ret = lxc_log_init(NULL, logpath, "INFO", "lxc-monitord", 0,
>> lxcpath);
>> if (ret)
>> return ret;
>>
>>
>>
>> > [caglar@qgq:~/Project/lxc/examples] ps aux |
>> > grep /usr/bin/lxc-monitord caglar1170 0.0 0.0 13580 940
>> > pts/3S+ 23:57 0:00 grep --color=auto /usr/bin/lxc-monitord
>> > root 29997 0.0 0.0 15000 744 ?Ss 23:47 0:00
>> > /usr/bin/lxc-monitord /var/lib/lxc 5
>> > [caglar@qgq:~/Project/lxc/examples] date
>> > Fri May 3 23:57:52 EDT 2013
>> >
>> > * And lastly here is what lxc-monitord.log shows
>> >
>> > [caglar@qgq:~/Project/lxc(clone)] tail
>> > -f /var/lib/lxc/lxc-monitord.log lxc-monitord 1367639242.631 NOTICE
>> > lxc_monitord - monitoring lxcpath /var/lib/lxc
>> >lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
>> >lxc-monitord 1367639242.633 NOTICE lxc_monitord - create failed
>> >lxc-monitord 1367639242.636 NOTICE lxc_monitord - create failed
>> >lxc-monitord 1367639242.639 NOTICE lxc_monitord - create failed
>> >lxc-monitord 1367639242.643 NOTICE lx
Re: [lxc-devel] lxc_monitord - monitor exiting
OK reproduced it with C API
26624lxc-monitord 1367687488.006 NOTICE lxc_monitord - monitoring
lxcpath /var/lib/lxc
26627lxc-monitord 1367687488.008 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26630lxc-monitord 1367687488.009 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26634lxc-monitord 1367687488.011 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26635lxc-monitord 1367687488.011 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26636lxc-monitord 1367687488.014 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26639lxc-monitord 1367687488.014 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26644lxc-monitord 1367687488.014 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26650lxc-monitord 1367687488.018 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26652lxc-monitord 1367687488.018 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.020 INFO lxc_monitord - accepted
client fd:5 clients:1
26624lxc-monitord 1367687488.020 INFO lxc_monitord - accepted
client fd:9 clients:2
26643lxc-monitord 1367687488.021 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26664lxc-monitord 1367687488.023 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.025 INFO lxc_monitord - accepted
client fd:10 clients:3
26667lxc-monitord 1367687488.026 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.028 INFO lxc_monitord - accepted
client fd:11 clients:4
26677lxc-monitord 1367687488.028 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26679lxc-monitord 1367687488.028 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.028 INFO lxc_monitord - accepted
client fd:12 clients:5
26680lxc-monitord 1367687488.031 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.031 INFO lxc_monitord - accepted
client fd:13 clients:6
26684lxc-monitord 1367687488.032 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26676lxc-monitord 1367687488.033 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.034 INFO lxc_monitord - accepted
client fd:14 clients:7
26624lxc-monitord 1367687488.034 INFO lxc_monitord - accepted
client fd:15 clients:8
26683lxc-monitord 1367687488.036 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.037 INFO lxc_monitord - accepted
client fd:16 clients:9
26690lxc-monitord 1367687488.038 INFO lxc_monitord - monitor fifo
/var/lib/lxc/monitor-fifo exists, already running?
26624lxc-monitord 1367687488.039 INFO lxc_monitord - accepted
client fd:17 clients:10
26624lxc-monitord 1367687488.748 INFO lxc_monitord - removing fd 15
26624lxc-monitord 1367687489.239 INFO lxc_monitord - removing fd 17
26624lxc-monitord 1367687489.395 INFO lxc_monitord - removing fd 16
26624lxc-monitord 1367687519.425 NOTICE lxc_monitord - # of clients: 7
code sits @ http://10ur.org/lxc/
On Sat, May 4, 2013 at 12:22 PM, S.Çağlar Onur wrote:
> Hi Dwight,
>
> I run same commands and this time it ended up with 6 clients (output ->
> http://10ur.org/monitor.txt). I'll try to reproduce this with c/python.;.
>
> On Sat, May 4, 2013 at 11:15 AM, S.Çağlar Onur wrote:
>
>> Hi Dwight,
>>
>> On Sat, May 4, 2013 at 9:16 AM, Dwight Engen wrote:
>>
>>> Hi Çağlar,
>>>
>>> I'm confused by your output, it certainly looks like something isn't
>>> right. Do you have a theory as to why monitord thinks it still has 9
>>> clients?
>>
>>
>> Nope, I don't. I'll try to debug more and also try to reproduce this with
>> python or c api to rule out go.
>>
>>
>>> On Sat, 4 May 2013 00:01:45 -0400
>>> S.Çağlar Onur wrote:
>>>
>>> > Hi all,
>>> >
>>> > I think I understand why I'm confused before while chasing another
>>> > bug. This is what I'm seeing right now.
>>> >
>>> > * I patched lxc_monitord.c with following
>>> >
>>> > diff --git a/src/lxc/lxc_monitord.c b/src/lxc/lxc_monitord.c
>>> > index e76af71..59f1e9d 100644
>>> > --- a/src/lxc/lxc_monitord.c
>>> > +++ b/src/lxc/lxc_monitord.c
>>> > @@ -373,6 +373,7 @@ int main(int argc, char *argv[])
>>> > }
>>> >
>>> > if (lxc_monitord_create(&mon)) {
>>
Re: [lxc-devel] [PATCH 1/1] lxc-create: add zfs support
On 04/21/2013 03:37 PM, Serge Hallyn wrote: > > Quoting Serge Hallyn (serge.hal...@ubuntu.com): >> Any feedback on this patch? >> >> I also have a question on behavior details. Until now, we've set up >> btrfs containers so that $lxcpath is a subvolume, and then each >> $rootfs is a subvolume. With zfs, per Papp's request, we're making >> the (zfs equivalent of a subvolume) at the $lxcpath/$lxc_name. So >> that means when we make a snapshot clone, we'll be doing them >> differently for different filesystems. >> >> I don't really care which we do - and even if we keep them different >> for hysterical raisins it's not biggie technically, since the >> filesystems have to be handled differently at clone anyway. But >> it'll be harder to explain to users what's going on. >> >> With the btrfs way, when we snapshot-clone a container we have to >> manually copy all the config and hooks files. We have to process >> them anyway (s/oldname/newname etc) though. With the zfs way we >> wouldn't have to copy them - so files which we didn't predict won't >> be copied. That may be a good thing - if we didn't predict it, then >> we probably didn't process it anyway so it may not be safe. Still >> the zfs way feels elegant... > > To reply to myself, > > as we also support snapshot-clones of lvm, and soon qcow and qed > based containers, and those will only snapshot the rootfs, if we > want behavior with all backing stores to be consistent then zfs > would need to change to only snapshot the rootfs, not $lxcpath/$lxc_name. What if it's optional or even detected? tamas -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/1] lxc-create: add zfs support
On 04/23/2013 10:51 PM, Stéphane Graber wrote: > If we don't set the block device as lxc.rootfs, then the host has to > mount the LVM outside of the container's mount namespace, which we > prefer not to have to do, especially as you get into a chicken and egg > problem where the LVM path is set in the file that's stored on an > unmounted LVM partition :) Yes, that's true. My question is that this setup will be possible? That's new to me, as right now AFAIK a rootfs can be only a directory. > We won't prevent you from putting your container on whatever storage you > want and setting lxc.rootfs to a standard fs path. That'll still work, My problem is that creating a 'standard' container with official tools will be pretty complicated. Standard means here, that lxc-create sets up correct configuration files, the guest OS is fine tuned, volume is created...etc. Now it's easy, nice and comfortable, lightweight as the whole project. > it's just that clone won't detect it's LVM backed and so won't create a > new LV (instead it'll just create a new entry under /var/lib/lxc and > rsync the content). That's correct and clear. tamas -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3612432 ] LXC 0.9.0 fails to build on CentOS6 if -Werror is used
Bugs item #3612432, was opened at 2013-05-01 12:07 Message generated for change (Tracker Item Submitted) made by robbiesz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Szabo (robbiesz) Assigned to: Nobody/Anonymous (nobody) Summary: LXC 0.9.0 fails to build on CentOS6 if -Werror is used Initial Comment: Compilation on CentOS6 (gcc 4.4.6) fails with these two errors: gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-conf.o -MD -MP -MF .deps/liblxc_so-conf.Tpo -c -o liblxc_so-conf.o `test -f 'conf.c' || echo './'`conf.c cc1: warnings being treated as errors conf.c: In function 'setup_caps': conf.c:1725: warning: comparison is always false due to limited range of data type conf.c:1725: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-conf.o] Error 1 AND gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-caps.o -MD -MP -MF .deps/liblxc_so-caps.Tpo -c -o liblxc_so-caps.o `test -f 'caps.c' || echo './'`caps.c cc1: warnings being treated as errors caps.c: In function '_real_caps_last_cap': caps.c:204: warning: comparison is always false due to limited range of data type caps.c:204: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-caps.o] Error 1 Configuration options: $ ./configure --prefix=/software/lxc/0.9.0/linux.centos6.x86_64 --with-pic --disable-apparmor --with-config-path=/var/lib/lxc --with-rootfs-path=/var/lib/lxc/rootfs --disable-doc The attached patch attempts fix these errors by changing the variable type to 'long'. Rob -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3612432 ] LXC 0.9.0 fails to build on CentOS6 if -Werror is used
Bugs item #3612432, was opened at 2013-05-01 12:07 Message generated for change (Settings changed) made by robbiesz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: liblxc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Szabo (robbiesz) Assigned to: Nobody/Anonymous (nobody) Summary: LXC 0.9.0 fails to build on CentOS6 if -Werror is used Initial Comment: Compilation on CentOS6 (gcc 4.4.6) fails with these two errors: gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-conf.o -MD -MP -MF .deps/liblxc_so-conf.Tpo -c -o liblxc_so-conf.o `test -f 'conf.c' || echo './'`conf.c cc1: warnings being treated as errors conf.c: In function 'setup_caps': conf.c:1725: warning: comparison is always false due to limited range of data type conf.c:1725: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-conf.o] Error 1 AND gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-caps.o -MD -MP -MF .deps/liblxc_so-caps.Tpo -c -o liblxc_so-caps.o `test -f 'caps.c' || echo './'`caps.c cc1: warnings being treated as errors caps.c: In function '_real_caps_last_cap': caps.c:204: warning: comparison is always false due to limited range of data type caps.c:204: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-caps.o] Error 1 Configuration options: $ ./configure --prefix=/software/lxc/0.9.0/linux.centos6.x86_64 --with-pic --disable-apparmor --with-config-path=/var/lib/lxc --with-rootfs-path=/var/lib/lxc/rootfs --disable-doc The attached patch attempts fix these errors by changing the variable type to 'long'. Rob -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/1] lxc-create: add zfs support
On 04/23/2013 09:59 PM, Stéphane Graber wrote: > On 04/23/2013 01:28 AM, Serge Hallyn wrote: >> Quoting Stéphane Graber (stgra...@ubuntu.com): >>> I'm not a big user of lxc-clone (yet) but I think as we redesign that >>> part of the code, consistency across backend should be a primary goal >>> even if that causes some slight changes in behaviour from previous >>> implementations. >> >> Ok it finally dawned on me that if we want consistency, then we can't >> do it the new way. LVM backed containers are the primary counter >> example. To have $lxc_path/$lxc_name be lvm-backed would require >> the LV to be mounted at host boot. >> >> So what I'm going to do is implement a few more backing stores and >> a tiny temporary toy lxc-clone c program for easier testing, with >> zfs for now switched to only its rootfs being a separate zfs unit. >> We can't decide to switch all backing stores to the other way, but >> if we decide to later support zfs and btrfs having $lxcpath/$lxcname >> be separate units/subvolumes, it shouldn't be a big deal to special >> case that and support both. But I'd rather not complicate what I'm >> doing with that now. >> >> -serge > > I'm perfectly happy with only the rootfs being on a separate backend. > > Technically all block based backends (lvm, qcow2, raw disk image, ...) > will require that anyway. The only two cases where that's not > necessarily true is zfs and btrfs as those two aren't blocks but fs > sub-volumes and so effectively visible as directories and don't require > explicit mounting to be accessible. Why does LVM require that? As I understand, only image based setups do. Or you mean rootfs will be specified as a block device? I think it's possible with btrfs and zfs as well. Anyway, I still don't see, why it cannot be optional and create containers, that are maybe not compatible with lxc-clone. tamas -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] libvirt_lxc start lxc container problem when selinux enbale
Hi，all： the problem came out when selinux was enforced in targeted+MCS I start lxc through virsh――“virsh -c lxc:/// start instance-4bd6” 1. When selinux is Permissive，lxc start is ok The result of “Ps auxZ” is： system_u:system_r:virtd_lxc_t:s0-s0:c0.c1023 root 19218 0.0 0.0 47624 1244 ? Ss 15:26 0:00 /usr/libexec/libvirt_lxc --name system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19219 0.3 0.0 19276 1532 ? Ss 15:26 0:00 /sbin/init system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19406 0.0 0.0 177444 1332 ? Sl 15:26 0:00 /sbin/rsyslogd -i /var/run/sysl system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19420 0.0 0.0 64120 1144 ? Ss 15:26 0:00 /usr/sbin/sshd system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19427 0.0 0.0 22136 956 ? Ss 15:26 0:00 xinetd -stayalive -pidfile /var system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19434 0.0 0.0 64316 832 ? Ss 15:26 0:00 /usr/sbin/saslauthd -m /var/run system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19435 0.0 0.0 64316 600 ? S15:26 0:00 /usr/sbin/saslauthd -m /var/run system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19450 0.0 0.0 82388 2392 ? Ss 15:26 0:00 sendmail: rejecting new message system_u:system_r:svirt_lxc_net_t:s0:c192,c392 51 19459 0.0 0.0 78116 2016 ? Ss 15:26 0:00 sendmail: Queue runner@01:00:00 system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19467 0.0 0.0 175528 3672 ? Ss 15:26 0:00 /usr/sbin/httpd system_u:system_r:svirt_lxc_net_t:s0:c192,c392 48 19470 0.0 0.0 175528 2204 ? S15:26 0:00 /usr/sbin/httpd system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19475 0.0 0.0 117212 1348 ? Ss 15:26 0:00 crond system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 19491 0.0 0.0 4108 600 pts/0 Ss+ 15:26 0:00 /sbin/mingetty /dev/tty1 We can get into the lxc through “ssh” 2. When selinux is Enforcing，lxc start bad Th result of “ps auxZ” is: system_u:system_r:virtd_lxc_t:s0-s0:c0.c1023 root 20624 0.0 0.0 47624 1244 ? Ss 15:29 0:00 /usr/libexec/libvirt_lxc --name system_u:system_r:svirt_lxc_net_t:s0:c192,c392 root 20625 0.0 0.0 17172 1036 pts/0 Ss+ 15:29 0:00 /sbin/init Only /sbin/init process started, no else. This is the real problem There is no avc error messages in dmesg、/var/log/messages、/var/log/secure, and the same with selinux is Permissive Can anybody give some hints? Here are some system information: Kernel version 3.3.4 Libvirt version 0.9.13 Lxc guest image Centos 6.3 Lxc xml info is: instance-4bd6 96eada0e-7ea0-4865-8271-3565811c8eb0 524288 524288 1 exe /sbin/init console=ttyS0 destroy restart destroy /usr/libexec/libvirt_lxc system_u:system_r:svirt_lxc_net_t:s0:c192,c392 Best Regard Huangchaochang -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3611609 ] Configuration files are comment-location sensative
Bugs item #3611609, was opened at 2013-04-22 14:38 Message generated for change (Tracker Item Submitted) made by marphod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3611609&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: liblxc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Galen G. Brownsmith (marphod) Assigned to: Nobody/Anonymous (nobody) Summary: Configuration files are comment-location sensative Initial Comment: Platform: CentOS6.4, with a 3.8.8 Xen-enabled Kernel (kernel-xen repository) LXC Version: 0.8.0-rc2 (rpmforge repository) Command line: lxc-start -n centos-template -l DEBUG -o start.log The entire content of the error log was (set at DEBUG) when starting the container: lxc-start 135027.366 ERRORlxc_confile - Success - invalid ipv4 broadcast address: 192.168.253.9 lxc-start 135027.366 ERRORlxc_start_ui - failed to read configuration file (The logging level of the first line is a separate issue, but problematic. Probably should be NOTICE or INFO) In the end, I discovered that the lines in my config file that were problematic were lxc.network.hwaddr=4A:59:43:49:30:BF # REMEMBER TO CHANGE FOR EACH INSTANCE lxc.network.ipv4=192.168.253.9/24# REMEMBER TO CHANGE FOR EACH INSTANCE It did not matter where in the config file these lines were located (that is, it didn't matter if there were valid config lines following or preceeding these lines). Removing the comment (or moving it to its own line) was sufficient to fix the problem. (I'm guessing that this is liblxc, rather than some other category. It could quite possibly be a bug in a 3rd party tool used to parse the config files.) (summary: config files, probably low priority, probably should document if not fixed.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3611609&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
