Re: [vserver] Problem with host process ending up to be child of guest process

From: Herbert Poetzl <>
Date: Mon 13 Oct 2014 - 13:13:02 BST
Message-ID: <>

On Mon, Oct 13, 2014 at 11:47:48AM +0000, Fiedler Roman wrote:
> Hi,

> Thanks for your reply,

>> Von: Herbert Poetzl []

>> 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.

> Yes, but how can a host process become a child of a guest
> process in that way?

Ah, I obviusly misread that part _twice_, sorry :)

> Could some strange corner case/bug in setpgid cause that?


>>> 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.

> Version should be the latest available for download:

> Linux version 3.14.17-vs2.3.6.13 (root@localhost) (gcc version 4.8.2) #1 SMP
> Tue Sep 16 09:13:43 UTC 2014

> Command sequence is

> start-stop-daemon --start --background --make-pidfile --pidfile
> "/var/run/" --exec /usr/bin/socat EXEC:host-stdin-bridge
> "EXEC:vserver somename exec guest-stdout-bridge,nofork=1"

> When running the command, the host-stdin-bridge process running
> on the host will become the child of the guest-stdout-bridge
> command running in the guest, thus host process returning a
> guest-PID via getppid

Strange indeed.
Do you, by any chance, know if that works with LXC?

> I would expect the host process to have start-stop-daemon as
> parent at first, after termination if start-stop-daemon, I
> would guess getppid()=1 should be it for the host process.

>>> 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,

> OK

Received on Mon Oct 13 13:13:12 2014

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 13 Oct 2014 - 13:13:12 BST by hypermail 2.1.8