Hi Serge,
On Wed, Apr 17, 2013 at 6:02 PM, Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
> > From: "S.Çağlar Onur"
> >
> > Trying to start multiple containers concurrently may cause
> lxc_monitor_read_timeout to fail as select call could be interrupted by a
> signal, handle it.
Quoting S.Çağlar Onur (cag...@10ur.org):
> From: "S.Çağlar Onur"
>
> Trying to stop multiple containers concurrently ends up with "cgroup is not
> mounted" errors as multiple threads corrupts the shared variables.
> Fix that stack corruption and start to use getmntent_r to support stopping
> mu
Quoting S.Çağlar Onur (cag...@10ur.org):
> From: "S.Çağlar Onur"
>
> Trying to start multiple containers concurrently may cause
> lxc_monitor_read_timeout to fail as select call could be interrupted by a
> signal, handle it.
>
> Signed-off-by: S.Çağlar Onur
> ---
> src/lxc/state.c |9 +++
Quoting Richard Weinberger (rich...@nod.at):
> Reimplement mkdir_p() such that it:
> ...handles relativ paths correctly. (currently it crashes)
> ...does not rely on dirname().
> ...is not recursive.
> ...is shorter. ;-)
>
> Signed-off-by: Richard Weinberger
Thanks, this looks great.
Acked-
From: "S.Çağlar Onur"
Trying to stop multiple containers concurrently ends up with "cgroup is not
mounted" errors as multiple threads corrupts the shared variables.
Fix that stack corruption and start to use getmntent_r to support stopping
multiple containers concurrently.
Signed-off-by: S.Çağ
From: "S.Çağlar Onur"
Trying to start multiple containers concurrently may cause
lxc_monitor_read_timeout to fail as select call could be interrupted by a
signal, handle it.
Signed-off-by: S.Çağlar Onur
---
src/lxc/state.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
di
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi,
>
> That's up to you, I can keep them in my branch till we endup with a new
> monitor code or you can merge them now and they start to work with new
> monitor code later.
>
> I'm using git to send those patches and I can easily add signed-off lines
>
Am 17.04.2013 18:00, schrieb Serge Hallyn:
> Quoting Richard Weinberger (rich...@nod.at):
>> Reimplement mkdir_p() such that it:
>> ...handles relativ paths correctly. (currently it crashes)
>> ...does not rely on dirname().
>> ...is not recursive.
>> ...is shorter. ;-)
>
> Looks good, than
Well if we really want to go that route, we can
a. specify a monitor-port in $lxcpath/lxc.conf
b. write a world-unreadable $lxcpath/monitor-secret file
c. require catting $lxcpath/monitor-secret at initial connection
so /var/lib/lxc/lxc.conf can have monitor-port=9998, while
/home/serge/lxcbas
Hi,
That's up to you, I can keep them in my branch till we endup with a new
monitor code or you can merge them now and they start to work with new
monitor code later.
I'm using git to send those patches and I can easily add signed-off lines
(I even don't know why they are missing as I believe I u
Quoting Richard Weinberger (rich...@nod.at):
> Am 17.04.2013 18:00, schrieb Serge Hallyn:
> >Quoting Richard Weinberger (rich...@nod.at):
> >>Reimplement mkdir_p() such that it:
> >> ...handles relativ paths correctly. (currently it crashes)
> >> ...does not rely on dirname().
> >> ...is not rec
Hi Serge,
Yeah you are correct we need regular users to be able to monitor their own
containes. I guess we can encrypt the messages but I'm not going there :)
Cheers,
On Wed, Apr 17, 2013 at 8:52 AM, Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
> > Hi there,
> >
> > What abou
Reimplement mkdir_p() such that it:
...handles relativ paths correctly. (currently it crashes)
...does not rely on dirname().
...is not recursive.
...is shorter. ;-)
Signed-off-by: Richard Weinberger
---
src/lxc/utils.c | 48 +---
1 file changed, 1
Quoting Richard Weinberger (rich...@nod.at):
> Reimplement mkdir_p() such that it:
> ...handles relativ paths correctly. (currently it crashes)
> ...does not rely on dirname().
> ...is not recursive.
> ...is shorter. ;-)
Looks good, thanks. Yeah I prefer non-recursive. Three
comments though,
Quoting Richard Weinberger (rich...@nod.at):
> Am 17.04.2013 14:55, schrieb Serge Hallyn:
> >Quoting Richard Weinberger (rich...@nod.at):
> >>There is no need to use nested functions voodoo.
> >
> >I see no downside to this, but what is the upside?
>
> There is absolute no reason to use a GNU C ex
Am 17.04.2013 14:55, schrieb Serge Hallyn:
> Quoting Richard Weinberger (rich...@nod.at):
>> There is no need to use nested functions voodoo.
>
> I see no downside to this, but what is the upside?
There is absolute no reason to use a GNU C extension here which makes
the code incompatible to other
If the process in the new namespace dies very early
we have currently no chance to detect this.
The parent process will just die due to SIGPIPE
if it write to the fd used for synchronisation and
nobody will notice the real cause of the problem.
Install a SIGCHLD handler to detect the death.
Later
There is no need to use nested functions voodoo.
Signed-off-by: Richard Weinberger
---
src/lxc/lxc_init.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
index c83c2f1..e4c9a32 100644
--- a/src/lxc/lxc_init.c
+++ b/src/lxc
While we are here, fix the whitespace damage.
Signed-off-by: Richard Weinberger
---
src/lxc/lxc_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
index e4c9a32..84e1293 100644
--- a/src/lxc/lxc_init.c
+++ b/src/lxc/lxc_init.c
@@ -4
Quoting S.Çağlar Onur (cag...@10ur.org):
> From: "S.Çağlar Onur"
>
> Trying to start multiple containers concurrently may cause
> lxc_monitor_read_timeout to fail as select call could be interrupted by a
> signal, handle it.
Hi,
so if I understand right we're waiting on this for a redesign of
Quoting Richard Weinberger (rich...@nod.at):
> If the process in the new namespace dies very early
> we have currently no chance to detect this.
> The parent process will just die due to SIGPIPE
> if it write to the fd used for synchronisation and
> nobody will notice the real cause of the problem.
Quoting Richard Weinberger (rich...@nod.at):
> There is no need to use nested functions voodoo.
I see no downside to this, but what is the upside?
> Signed-off-by: Richard Weinberger
> ---
> src/lxc/lxc_init.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git
Quoting Richard Weinberger (rich...@nod.at):
> While we are here, fix the whitespace damage.
>
> Signed-off-by: Richard Weinberger
Acked-by: Serge E. Hallyn
> ---
> src/lxc/lxc_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_in
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi there,
>
> What about using AF_INET but binding a restricted port while adding a new
> field to the message? As an example we can start to create a hmac (or
> something like that) per container in the creation time and save that into
> LXCPATH/CONTAINE
24 matches
Mail list logo
