From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Fzw-0005dd-8R for qemu-devel@nongnu.org; Fri, 27 Nov 2015 05:11:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2Fzq-0006EV-82 for qemu-devel@nongnu.org; Fri, 27 Nov 2015 05:11:24 -0500 Received: from relay.parallels.com ([195.214.232.42]:46154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Fzq-0006Ax-0R for qemu-devel@nongnu.org; Fri, 27 Nov 2015 05:11:18 -0500 References: <1448478146-26246-1-git-send-email-den@openvz.org> <20151125222124.6284.52883@loki> <565741F4.6040707@virtuozzo.com> From: "Denis V. Lunev" Message-ID: <56582C30.7090206@parallels.com> Date: Fri, 27 Nov 2015 13:10:56 +0300 MIME-Version: 1.0 In-Reply-To: <565741F4.6040707@virtuozzo.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for 2.5 1/1] qga: added another non-interactive gspawn() helper file. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yuri Pudgorodskiy , Michael Roth , "Denis V. Lunev" Cc: qemu-devel@nongnu.org On 11/26/2015 08:31 PM, Yuri Pudgorodskiy wrote: > On 11/26/2015 1:21 AM, Michael Roth wrote: >> Quoting Denis V. Lunev (2015-11-25 13:02:26) >>> From: Yuri Pudgorodskiy >>> >>> With previous commit we added gspawn-win64-helper-console.exe, >>> required for gspawn() mingw implementation. >>> Unfortunatly when running as a service without interactive >>> desktop, gspawn() also requires another helper app. >>> >>> Added gspawn-win64-helper.exe and gspawn-win32-helper.exe >>> for corresponding architectures. >>> >>> Signed-off-by: Yuri Pudgorodskiy >>> Signed-off-by: Denis V. Lunev >>> CC: Michael Roth >> Thanks, applied to qga tree with minor whitespace fixup: >> >> https://github.com/mdroth/qemu/commits/qga >> >> I noticed something testing this though: if we run qemu-ga >> from a console, then exec something like ipconfig with >> capture-output: true, qemu-ga returns that output via >> guest-exec-status. >> >> If we run it as a service however, there's no output. >> >> # with qemu-ga started via console >> {'execute':'guest-exec','arguments':{'path':'/Windows/System32/ipconfig.exe', >> >> 'capture-output':true}} >> {"return": {"pid": 1644}} >> {'execute':'guest-exec-status','arguments':{'pid':1644}} >> {"return": {"exitcode": 0, "out-data": >> "DQpXaW5kb3dzIElQIENvbmZpZ3VyYXRpb24NCg0KDQpFdGhlcm5ldCBhZGFwdGVyIExvY2FsIEFyZWEgQ29ubmVjdGlvbiAyOg0KDQogICBDb25uZWN0aW9uLXNwZWNpZmljIEROUyBTdWZmaXggIC4gOiANCiAgIExpbmstbG9jYWwgSVB2NiBBZGRyZXNzIC4gLiAuIC4gLiA6IGZlODA6OjMwMDU6NmRjOjNjNmE6NTQ2NCUxNA0KICAgSVB2NCBBZGRyZXNzLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDogMTkyLjE2OC4xMjIuMTQNCiAgIFN1Ym5ldCBNYXNrIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA6IDI1NS4yNTUuMjU1LjANCiAgIERlZmF1bHQgR2F0ZXdheSAuIC4gLiAuIC4gLiAuIC4gLiA6IDE5Mi4xNjguMTIyLjENCg0KVHVubmVsIGFkYXB0ZXIgaXNhdGFwLns3Q0Q3OTAwQy05NThCLTRBRUMtQkUwRC0yMTNERjM1NjQ2MEZ9Og0KDQogICBNZWRpYSBTdGF0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOiBNZWRpYSBkaXNjb25uZWN0ZWQNCiAgIENvbm5lY3Rpb24tc3BlY2lmaWMgRE5TIFN1ZmZpeCAgLiA6IA0KDQpUdW5uZWwgYWRhcHRlciBMb2NhbCBBcmVhIENvbm5lY3Rpb24qIDExOg0KDQogICBNZWRpYSBTdGF0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOiBNZWRpYSBkaXNjb25uZWN0ZWQNCiAgIENvbm5lY3Rpb24tc3BlY2lmaWMgRE5TIFN1ZmZpeCAgLiA6IA0K", >> >> "exited": true}} >> >> # wtih qemu-ga started via windows service >> {'execute':'guest-exec','arguments':{'path':'/Windows/System32/ipconfig.exe', >> >> 'capture-output':true}} >> {"return": {"pid": 1176}} >> {'execute':'guest-exec-status','arguments':{'pid':1176}} >> {"return": {"exitcode": 0, "exited": true}} >> >> Is this expected? >> > > No, we want to fix it somehow - but not now, because the whole > picture is not clear yet. > Looks like when running gspawn() from a win32 service, some win32 > processes open > its own console and write stdout to it instead of parent's fd > inherited from gspawn-helper. > > Not sure whether it can be corrected without patching gspawn() and > gspawn-helper code or not. > If so, we may consider implementing platform-specific version of > guest-exec using win32 api. > > Right now the best what can be suggested, it is a workaround: usage of > redirection on guest side. > > Executing 3 commands in a row do a trick > > cmd /c ipconfig >out.txt > cmd /c type out.txt > cmd /c del out.txt > > but looks ugly and error-prone. > > One more pity notice, it seems that gspawn-helper does incorrect quoting: > > cmd /c echo "hello" > > produces \"hello\" output instead of expected "hello". > Again, quoting issue may be another point for implementing better > win32-specific guest-exec. > > I'll share my visions on this problem later after some experiments. > > no for me this smells like GLIB bug which should be addressed separately. Den