On Mon, Oct 13, 2014 at 08:52:36AM +0000, Fiedler Roman wrote: > Hello List, > Analyzing a problem today, It seems the the root cause is, that > a host process ended up being the child of a guest process > after using "vserver exec". Not sure what you expect from "vserver exec" but it is intended to execute processes inside the guest after all. If the guest has no reaper/init running, every top level guest process will become a child of a host process. > Since the guest process is in the guest's PID namespace, tools > on the host fail to react accordingly, e.g. bash job-control > gets stuck or start-stop-daemon reacts unexpected. Maybe details about kernel/patch/util-vserver version as well as the problematic command sequence which causes the "unexpected" behaviour plus a description what the "expected" behaviour would be would help a lot. > Some questions to that: > * Can someone give a hint, how this could happen, thus being > able to attempt to fix the problem for now using a workaround? > * Is this caused by known behavior of vserver exec and misuse > from my side? > * No matter if misuse or bug, should this case be prevented > since it should also cause security risks? > A host process uses the parent pid of itself or another host > process, but parent pid is from guest namespace. So from my > understanding it could collide with PIDs from host namespace, > thus host process might operate on arbitrary other host > process, e.g. signalling or modifying it or just like with > bash, getting stuck running wait(-1) in endless loop? Let's get some details first, thanks, Herbert > Roman