Quoting Qiang Huang (h.huangqi...@huawei.com):
> 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.
The disaster would be that the caller might do something like:
c->want_daemonize(true);
if (c->start()) {
FILE *f = fopen("/run/running_containers", "a");
bump_container_count(f);
fclose(f);
}
Now the caller's thread will bump the running_containers count,
and then after the container shuts down, the (daemonized)
monitor thread (which never does an exec) will return and also
bump that count, making the count in /run/running_containers
wrong.
-serge
_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
