Control: tag -1 moreinfo unreproducible 28.10.2016 17:30, Brad Barnett wrote: > Package: qemu-system-x86 > Version: 1:2.1+dfsg-12+deb8u6 > > I've been unable to find anything about this via Google searches, > mailing list searches, IRC, you name it. Nor, does the documentation > seem to indicate I'm doing anything wrong. > > Additional queries to qemu-devel and qemu-discuss fell flat, with zero > replies. > > I'm starting qemu with various options, including this: > > -qmp unix:/path_to_sock_dir/box.uniquename.sock,server,nowait > > I'm using socat to connect: > > socat UNIX-CONNECT:/path_to_sock_dir/box.uniquename.sock STDIO [] > What happens is that randomly, socat can no longer connect to the socket > in question. This has happened after successful uses of that very > socket, and also if I've never used that socket before.
So, when socat isn't able to connect anymore, what does lsof /path_to_sock_dir/box.uniquename.sock says about it? Does the socket exist at all? There's no code in qemu to remove the socket or to mess with it in any other way during runtime, and has never been. The same code is used for all other unix sockets too, be it monitor (hmp), vnc or other things. If the socket is being deleted or moved, it is done outside qemu. For example, you can use mv(1) or rm(1) tool to do so, and socat will return exactly the error you mentioned above. If you try to start another qemu with the same socket, that socket will be overridden too. If you exit qemu listening on that socket, the socket will refuse connections as well. I myself used various sokets in qemu, including qmp, countless number of times, and right now all my VMs run with qmp unix socket enabled. Libvirt, the main qemu management interface, uses it too. So I'm really unsure what's going on here. It looks like something specific to your environment, please check the above variants. Thanks, /mjt
