[lxc-devel] [PATCH 1/2] lxc-start: fix the container leak when daemonize

[Qiang Huang]

Hi Serge,

On 2014/1/20 23:44, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqiang at huawei.com):
>> On 2014/1/20 1:26, Serge Hallyn wrote:
>>> Quoting Qiang Huang (h.huangqiang at 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.

The real world daemonized monitor thread dose an exec ;)

But yes, I agree we can do some bad things based on this scenario,
a new process should exit rather than return to where his
birth function was called.

Thanks Serge.

> 
> -serge
> 
>