On 2014/1/21 11:20, Stéphane Graber wrote: > On Tue, Jan 21, 2014 at 10:54:50AM +0800, Qiang Huang wrote: >> Hi Stéphane, >> >> I'm not sure I understand this. >> >> In my understanding, anything using the API to control an already >> running backgrounded container will use lxc_container_new to create >> a new lxc_container, it only share the original one's name and config >> and so on. After dealing, will call lxc_container_put to free this >> lxc_container, this *new* lxc_container doesn't contain the PID file >> information, so it's freeing won't remove PID file. > > Hmm, yeah, seems like you're right, I should have rechecked the patch > rather than speak from the vague memory of what I saw when you initialy > posted it. > > > So, re-reading more carefully, I don't completely disagree with the > approach, though I don't like having to extend lxc_container just for > that...
Without 1/2 patch, this patch won't work, I'll send new patches. So would it be better if I put this into lxc_conf? > > There's however one rather big problem, the PID file will contain the > wrong PID. The PID being written is getpid() from the parent lxc-start, > not the running, forked lxc-start process and that child PID is only > known by the start() function in lxccontainer.c, so you can't create the > PID file from lxc_start.c Yeah, I noticed that before, I thought that's exactly what we want, because we can get the init pid of container from lxc_info command. If it's not, we can fix it incrementally. :) > _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel