Re: pidns memory leak
From: Daniel Lezcano
Date: Tue Oct 06 2009 - 04:20:13 EST
Sukadev Bhattiprolu wrote:
Daniel Lezcano [dlezcano@xxxxxxxxxx] wrote:
Hi,
I am facing a problem with the pid namespace when I launch the following
lxc commands:
lxc-execute -n foo sleep 3600 &
ls -al /proc/$(pidof lxc-init)/exe && lxc-stop -n foo
All the processes related to the container are killed, but there is
still a refcount on the pid_namespace which is never released.
Thanks for the bug report.
Did you notice any leak in 'struct pids' also or just the pid_namespace ?
If the pids are not leaking, this may be slightly different from the problem
Catalin Marinas ran into:
http://lkml.org/lkml/2009/7/29/406
I am not sure what you mean by 'struct pids' but what I observed is:
pid_2 and pid_namespace (as they are named in /proc/slabinfo) are never
decremented.
And the pid_namespace does not seem to reproduce for me, with out the
'ls -al /proc/...' above, or with the simpler 'ns_exec' approach to
creating pid namespace.
I tried to write a simpler program but I failed to reproduce it.
I am going through the code for lxc-execute, but does it remount /proc
in the container ?
Right, the parent does a clone(NEWMNT|NEWPID|NEWIPC|NEWUTS), wait for
the child while this one (pid 1) 'execs' the lxc-init process. This
program mounts /proc and fork-exec the command passed as parameter (here
'sleep 3600').
Without this intermediate process, the leak *seems* not happening.
If you don't access /proc/<pid>/<file>, the leak is not happening.
So to summarize:
Leak when:
----------
lxc-execute -n foo sleep 3600 &
ls -al /proc/$(pidof sleep)/exe && lxc-stop -n foo
The stop can be done, immediately after looking at the proc file or
later, the leak happens in all the cases.
No leak when:
-------------
lxc-execute -n foo sleep 3600 &
lxc-stop -n foo
I tried to create a simpler program doing the same but that did not
triggered the problem.
-- Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/