On Sun, May 26, 2013 at 05:13:36PM +0200, Stefan Priebe wrote: > Am 26.05.2013 03:23, schrieb mdroth: > >On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote: > >>Am 25.05.2013 00:32, schrieb mdroth: > >>>On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote: > >>>>Am 25.05.2013 00:09, schrieb mdroth: > >>>>>>>>>I would try to create a small example script. > >>>>>>>> > >>>>>>>>I use qmp-shell and other little scripts very often. > >>>>>>>> > >>>>>>>>>Am this be due to the fact that I don't wait for the welcome banner > >>>>>>>>>right now? > >>>>>>>> > >>>>>>>>If you're not reading from the socket, then you'll get the banner back > >>>>>>>>when > >>>>>>>>you read your first response. But qom-set shouldn't fail because of > >>>>>>>>that. > >>>>>> > >>>>>>I can workaround it by adding this patch: > >>>>>>diff --git a/monitor.c b/monitor.c > >>>>>>index 62aaebe..9997520 100644 > >>>>>>--- a/monitor.c > >>>>>>+++ b/monitor.c > >>>>>>@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque) > >>>>>> static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name) > >>>>>> { > >>>>>> int is_cap = compare_cmd(cmd_name, "qmp_capabilities"); > >>>>>>- return (qmp_cmd_mode(mon) ? is_cap : !is_cap); > >>>>>>+// return (qmp_cmd_mode(mon) ? is_cap : !is_cap); > >>>>>>+ return ((is_cap > 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap)); > >>>>>> } > >>>>> > >>>>>I think this is unrelated to your original issue. If you issue > >>>>>'qmp_capabilities' command more than once you will get CommandNotFound, > >>>>>and that behavior seems to be present even with v1.3.0. This patch seems > >>>>>to be masking the problem you're having (which seems to be state from > >>>>>previous monitor sessions/connections leaking into subsequent ones). > >>>> > >>>>That sounds reasonable. I'm using proxmox / PVE which does a lot of > >>>>qmp queries in the background. So i might see situations where X > >>>>connections in parallel do qmp queries. > >>>> > >>>>>It's possible the GSource-based mechanism for handling I/O for chardev > >>>>>backends is causing a difference in behavior. Still not sure exactly > >>>>>what's going on though. > >>>>Can i revert some patches to test? > >>> > >>>I think somewhere prior to this one should be enough to test: > >>> > >>>2ea5a7af7bfa576a5936400ccca4144caca9640b > >> > >>YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests > >>and this works absoluty fine. > > > >Turns out the real culprit was a few commits later: > > > >9f939df955a4152aad69a19a77e0898631bb2c18 > > > >I've sent a workaround this fixes things for QMP, but we may need a more > >general fix. Please give it a shot and see if it fixes your issues: > > > >http://article.gmane.org/gmane.comp.emulators.qemu/213106 > > no i got again: > The command qom-set has not been found JSON Reply: {"id": > "21677:2", "error": {"class": "CommandNotFound", "desc": "The > command qom-set has not been found"}} JSON Query: > {"execute":"qom-set","id":"21677:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}} > at /usr/share/perl5/PVE/QMPClient.pm line 101.
Darn, I noticed another potential race after I sent the patch. Hadn't been able to trigger it on my end, but it might be what you're hitting. Just sent a v2, can you give that a shot? http://article.gmane.org/gmane.comp.emulators.qemu/213147 > > Stefan >