On my system, the command `qemu-system-x86_64` prints no output and
simply hangs. No display window appears. Apparently QEMU hangs while
polling dbus.
If I run `strace qemu-system-x86_64`, the end of the output is:
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
connect(8, {sa_family=AF_UNIX, sun_path="/tmp/dbus-4fpXSf1PZL"}, 22) = 0
fcntl(8, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(8, F_SETFL, O_RDWR|O_NONBLOCK) = 0
geteuid() = 1000
getsockname(8, {sa_family=AF_UNIX}, [128 => 2]) = 0
poll([{fd=8, events=POLLOUT}], 1, 0) = 1 ([{fd=8, revents=POLLOUT}])
sendto(8, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(8, "AUTH EXTERNAL 31303030\r\n", 24, MSG_NOSIGNAL, NULL, 0) = 24
poll([{fd=8, events=POLLIN}], 1, -1
My system is running Ubuntu, but I installed Ubuntu manually (using
custom scripts I wrote), so it is entirely possible that dbus is not
behaving as expected. (I have deliberately disabled or removed many
Ubuntu components that are present on a "standard" installation of
Ubuntu.)
Is it possible to prevent QEMU from attempting to use dbus?
Afaik, qemu shouldn't use dbus by default. But the gtk display might trigger a dbus path. Can you provide a backtrace of this hang?
thanks
Does anyone have any suggestions for diagnosing the problem? QEMU is
not printing any error or diagnostic messages. If dbus writes any
error or log messages, I don't know where they would be.
If I move the socket /tmp/dbus-4fpXSf1PZL to some other path, then it
appears that QEMU runs successfully. (Presumably, in this case QEMU
skips trying to connect to dbus.)
Thank you,
Parke