Those go through commands.c and are already mutex'ed that way.
Also remove a unmatched container_disk_unlock in lxcapi_create.
Since is_stopped uses getstate which is no longer locked, rename
it to drop the _locked suffix.
And convert save_config to taking the disk lock. This way the
save_ and
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Tue, 28 May 2013 17:03:43 -0400
> Stéphane Graber wrote:
>
> > On 05/28/2013 04:53 PM, Serge Hallyn wrote:
> > > Quoting Stéphane Graber (stgra...@ubuntu.com):
> > >> Hey everyone,
> > >>
> > >> Thanks for the feedback on my previous autostart
On Tue, 28 May 2013 17:03:43 -0400
Stéphane Graber wrote:
> On 05/28/2013 04:53 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgra...@ubuntu.com):
> >> Hey everyone,
> >>
> >> Thanks for the feedback on my previous autostart proposal.
> >>
> >> Here's a detailed bullet-point list of what
On Tue, 2013-05-28 at 15:53 -0500, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
> > Hey everyone,
> >
> > Thanks for the feedback on my previous autostart proposal.
> >
> > Here's a detailed bullet-point list of what should be done to implement
> > autostarting containers
On 05/28/2013 04:37 PM, Michael H. Warfield wrote:
> On Tue, 2013-05-28 at 15:58 -0400, Stéphane Graber wrote:
>> Hey everyone,
>
>> Thanks for the feedback on my previous autostart proposal.
>
>> Here's a detailed bullet-point list of what should be done to implement
>> autostarting containers
On 05/28/2013 04:53 PM, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
>> Hey everyone,
>>
>> Thanks for the feedback on my previous autostart proposal.
>>
>> Here's a detailed bullet-point list of what should be done to implement
>> autostarting containers in upstream LXC.
>>
Quoting Qiang Huang (h.huangqi...@huawei.com):
> We should use the fd specified by caller.
>
> Signed-off-by: Qiang Huang
No effective change now, but technically correct.
Acked-by: Serge E. Hallyn
> ---
> src/lxc/lxc_console.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Quoting Dwight Engen (dwight.en...@oracle.com):
> Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
> ---
> lxc.spec.in | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/lxc.spec.in b/lxc.spec.in
> index 5e520c5..e00e60b 100644
> --- a/lxc.spec.in
> +++ b/lxc.spec.in
> @@ -104,7 +10
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Hey everyone,
>
> Thanks for the feedback on my previous autostart proposal.
>
> Here's a detailed bullet-point list of what should be done to implement
> autostarting containers in upstream LXC.
>
> Changes to the container config:
> - ADD: lxc.
On Tue, 2013-05-28 at 15:58 -0400, Stéphane Graber wrote:
> Hey everyone,
> Thanks for the feedback on my previous autostart proposal.
> Here's a detailed bullet-point list of what should be done to implement
> autostarting containers in upstream LXC.
Yes. I concur with virtually (excuse the p
(fyi - I've pushed this to staging to lxc-clone to work again.)
Switch lxcapi_clone to use the non-locking is_stopped_locked() instead
of c->is_running.
Technically as (IIRC) Dwight has mentioned we should probably drop the
locking from api_state() altogether, since those are protected through th
Hey everyone,
Thanks for the feedback on my previous autostart proposal.
Here's a detailed bullet-point list of what should be done to implement
autostarting containers in upstream LXC.
Changes to the container config:
- ADD: lxc.start.auto (integer, 0 = disabled, 1 = enabled, default: 0)
- AD
On Tue, 2013-05-28 at 14:25 +, Jäkel, Guido wrote:
> >> So I'd rather not abuse the sticky bit for that kind of thing,
> >> especially as there's no good reason to do so.
> >> We can very simply create a separate state file that's removed on
> >> shutdown, or just use the one we already have (
Make lxc_cmd_console() return the fd from the socket connection to the
caller. This fd keeps the tty slot allocated until the caller closes
it. Returning the fd allows for a long lived process to close the fd
and reuse consoles.
Add API function for console allocation.
Create test program for con
Signed-off-by: Dwight Engen
---
lxc.spec.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/lxc.spec.in b/lxc.spec.in
index 5e520c5..e00e60b 100644
--- a/lxc.spec.in
+++ b/lxc.spec.in
@@ -104,7 +104,6 @@ rm -rf %{buildroot}
%attr(4111,root,root) %{_bindir}/lxc-attach
%attr(4111,root,root) %{
Signed-off-by: Serge Hallyn
---
doc/lxc.conf.sgml.in | 139 +++
1 file changed, 139 insertions(+)
diff --git a/doc/lxc.conf.sgml.in b/doc/lxc.conf.sgml.in
index af8663a..6500e50 100644
--- a/doc/lxc.conf.sgml.in
+++ b/doc/lxc.conf.sgml.in
@@ -76,6
Hey all...
On Tue, 2013-05-28 at 09:19 -0400, Stéphane Graber wrote:
> On 05/28/2013 03:14 AM, Natanael Copa wrote:
> > On Mon, 27 May 2013 15:07:03 -0400
> > Stéphane Graber wrote:
> >
> >> Hello,
> >>
> >> One feature that distros have been hacking together on their side for a
> >> while is c
On Tue, 28 May 2013 09:57:13 -0400
"Michael H. Warfield" wrote:
> On Tue, 2013-05-28 at 09:29 -0400, Stéphane Graber wrote:
> > On 05/28/2013 05:11 AM, Jäkel, Guido wrote:
> > > Dear Stéphane,
> > >
> > > To my opinion, we have to deal with two independent things:
> > > System crash recovery an
On Mon, 27 May 2013 15:07:03 -0400
Stéphane Graber wrote:
> Hello,
>
> One feature that distros have been hacking together on their side for
> a while is container autostart.
>
> For 1.0 I'd like us to agree on an upstream implementation of this so
> distros no longer need to carry patches in l
>> So I'd rather not abuse the sticky bit for that kind of thing,
>> especially as there's no good reason to do so.
>> We can very simply create a separate state file that's removed on
>> shutdown, or just use the one we already have (rootfs.hold).
>
>I have to also concur with this. I would be ap
Quoting 魏子然 (duck_...@163.com):
> Hello, we encounter a problem in the use of lxc, that the command of free
> and top does
> not show container\'s cpu and memory but the host server\'s;we know that it
> is a problem
> of proc directory which is mounted outside the container with remount
> opt
On Tue, 2013-05-28 at 09:29 -0400, Stéphane Graber wrote:
> On 05/28/2013 05:11 AM, Jäkel, Guido wrote:
> > Dear Stéphane,
> >
> > To my opinion, we have to deal with two independent things: System crash
> > recovery and container startup/shutdown dependencies
> >
> >> Another problem with this
On 05/28/2013 05:11 AM, Jäkel, Guido wrote:
> Dear Stéphane,
>
> To my opinion, we have to deal with two independent things: System crash
> recovery and container startup/shutdown dependencies
>
>> Another problem with this implementation is that the autostart flag is
>> lost when migrating the
On 05/28/2013 03:14 AM, Natanael Copa wrote:
> On Mon, 27 May 2013 15:07:03 -0400
> Stéphane Graber wrote:
>
>> Hello,
>>
>> One feature that distros have been hacking together on their side for a
>> while is container autostart.
> ...
>
>> So I therefore have two proposals on how to implement t
Le lundi 27 mai 2013 à 15:07 -0400, Stéphane Graber a écrit :
> Hello,
>
> One feature that distros have been hacking together on their side for a
> while is container autostart.
>
> For 1.0 I'd like us to agree on an upstream implementation of this so
> distros no longer need to carry patches in
Dear Stéphane,
To my opinion, we have to deal with two independent things: System crash
recovery and container startup/shutdown dependencies
>Another problem with this implementation is that the autostart flag is
>lost when migrating the container to another host. One needs to manually
>remove t
If the package manager, apk-tools is missing, then:
- download a static binary and public keys
- verify the keys against embedded checksum
- verify the signature of the static binary against the downloaded keys
- use the verified static binary
Signed-off-by: Natanael Copa
Signed-off-by: Kaarl
On Mon, 27 May 2013 15:07:03 -0400
Stéphane Graber wrote:
> Hello,
>
> One feature that distros have been hacking together on their side for a
> while is container autostart.
...
> So I therefore have two proposals on how to implement this, let me know
> what you prefer:
> 1)
> - Keep things a
28 matches
Mail list logo
