25.05.2013 04:34, Qiang Huang wrote:
> On 2013/5/24 20:49, Serge Hallyn wrote:
>>
>> Could you tell us exactly which version this is, and exactly how you
>> created the container? When I do it in ubuntu saucy (roughly 0.9.0 lxc),
>> the cgroup gets correctly removed.
The same issue has biten me s
On Fri, 24 May 2013 19:17:14 -0500
Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > Quoting Dwight Engen (dwight.en...@oracle.com):
> > > There were several memory leaks in the cgroup functions, notably
> > > in the success cases.
> > >
> > > The cgpath test program was
On 2013/5/24 20:49, Serge Hallyn wrote:
>
> Could you tell us exactly which version this is, and exactly how you
> created the container? When I do it in ubuntu saucy (roughly 0.9.0 lxc),
> the cgroup gets correctly removed.
>
>
My lxc version is 0.9.0(latest commit e9831f83532184), host os is
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > There were several memory leaks in the cgroup functions, notably in the
> > success cases.
> >
> > The cgpath test program was refactored and additional tests added to it.
> > It was used in vario
Quoting Dwight Engen (dwight.en...@oracle.com):
> Looks good to me, much cleaner in lxccontainer.c, nice! Minor question:
> can lxclock() and lxcunlock() be made static now?
Oh, heh, except src/test/locktests.c is still testing lxclock by hand :)
So it'll have to be updated to use the wrapper fu
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 24 May 2013 16:09:59 -0500
> Serge Hallyn wrote:
>
> > ( These are pushed to github.com/hallyn/lxc branch
> > lxclock-flock.rebase )
> >
> > Create three pairs of functions:
> > int process_lock(void);
> > void process_unlock(void
Quoting Dwight Engen (dwight.en...@oracle.com):
> There were several memory leaks in the cgroup functions, notably in the
> success cases.
>
> The cgpath test program was refactored and additional tests added to it.
> It was used in various modes under valgrind to test that the leaks were
> fixed.
Quoting Dwight Engen (dwight.en...@oracle.com):
> This fixes the build of lxccontainer.c on systems that have __NR_setns
> but not HAVE_SETNS.
>
> Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
> ---
> src/lxc/attach.c | 34 +-
> src/lxc/bdev.c
On Fri, 24 May 2013 16:09:59 -0500
Serge Hallyn wrote:
> ( These are pushed to github.com/hallyn/lxc branch
> lxclock-flock.rebase )
>
> Create three pairs of functions:
> int process_lock(void);
> void process_unlock(void);
> int container_mem_lock(struct lxc_container *c)
>
( These are pushed to github.com/hallyn/lxc branch lxclock-flock.rebase )
Create three pairs of functions:
int process_lock(void);
void process_unlock(void);
int container_mem_lock(struct lxc_container *c)
void container_mem_unlock(struct lxc_container *c)
i
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 24 May 2013 08:09:21 -0500
> > -sem_t *lxc_newlock(const char *name)
> > +struct lxc_lock *lxc_newlock(const char *lxcpath, const char *name)
> > {
> > - char *lname;
> > - sem_t *lock;
> > + struct lxc_lock *l;
> > + int ret = pthr
Oh, but OTOH, making two of the lock functions member functions
of the container struct encourages applications to use them -
which we may not want.
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the on
Quoting Dwight Engen (dwight.en...@oracle.com):
> I think the names you've got are fine (don't really have a better
> idea), I do think its good to name locks by what they cover. Its a bit
> tricky here because one is a process (and thread) lock and the other
> is just a thread lock and it would be
On Fri, 24 May 2013 10:40:30 -0500
Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > On Fri, 24 May 2013 08:23:57 -0500
> > Serge Hallyn wrote:
> >
> > > Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > > > The problem: if a task is killed while holding a posix
> > >
On Fri, 24 May 2013 08:09:21 -0500
Serge Hallyn wrote:
> The problem: if a task is killed while holding a posix semaphore,
> there appears to be no way to have the semaphore be reliably
> autmoatically released. The only trick which seemed promising
> is to store the pid of the lock holder in so
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 24 May 2013 08:23:57 -0500
> Serge Hallyn wrote:
>
> > Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > > The problem: if a task is killed while holding a posix semaphore,
> > > there appears to be no way to have the semaphore be reliab
On Fri, 24 May 2013 08:23:57 -0500
Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > The problem: if a task is killed while holding a posix semaphore,
> > there appears to be no way to have the semaphore be reliably
> > autmoatically released. The only trick which seemed
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> The problem: if a task is killed while holding a posix semaphore,
> there appears to be no way to have the semaphore be reliably
> autmoatically released. The only trick which seemed promising
> is to store the pid of the lock holder in some file a
The problem: if a task is killed while holding a posix semaphore,
there appears to be no way to have the semaphore be reliably
autmoatically released. The only trick which seemed promising
is to store the pid of the lock holder in some file and have
later lock seekers check whether that task has d
Quoting Qiang Huang (h.huangqi...@huawei.com):
> Hi,
>
> I found a tricky problem in LXC, once I made a mistake in config, set
>
> lxc.cgroup.cpuset.cpus = -1
>
> ofcourse start would fail, but then "lxc-ls --active" showed the container
> is active.
>
> error message is:
> # lxc-start -n hq111
Hi,
I found a tricky problem in LXC, once I made a mistake in config, set
lxc.cgroup.cpuset.cpus = -1
ofcourse start would fail, but then "lxc-ls --active" showed the container
is active.
error message is:
# lxc-start -n hq111 -f config_hq -l TRACE
lxc-start: Invalid argument - write /cgroup/lx
On Wed, 15 May 2013, Serge Hallyn wrote:
> > > Soon analogous create and destroy hooks will be added as well.
> >
> > I think I'd have preferred storing the command arguments in
> > LXC_CLONE_ARGS instead of directly in argv. Doing so would allow us to
> > remove/add other arguments without breaki
22 matches
Mail list logo
