On Fri, Mar 14, 2025 at 04:20:25PM +0100, Ján Tomko wrote:
On a Friday in 2025, Martin Kletzander wrote:I've bisected it to 28d4703a1f12711ab180e72db08a83bae59941df which is what I thought was the patch that changed the behaviour.What is that commit?
Well, that's because you did not check my local branch with the e-mail patches applied, have you! Of course that's a huckup on my part, but that's the one which tries keeping the connection to the dbus-daemon for running machines. Sorry.
Both my libvirt checkouts give me: fatal: bad object 28d4703a1f12711ab180e72db08a83bae59941df And even the web gives me a 404: https://gitlab.com/libvirt/libvirt/-/commit/28d4703a1f12711ab180e72db08a83bae59941df JanoI also noticed that we do not clean up the dbus-daemon config file when starting the domain fails. The diff in the configs is only the path. If I copy the config, run the dbus-daemon manually, change the socket path to /tmp/dbus-test.sock, then I can connect to it using: busctl --address=unix:path=/tmp/dbus-test.sock tree but if I try that for the libvirt-started dbus-daemon I cannot, and it does not matter whether that is with or without your patches. So there is something else going on, but the patch that is trying to keep the connection to the dbus-daemon exposes it. I guess something is wrong on my side and there is no reason for it to block these patches. Even when I added DBUS_VERBOSE=1 to the libvirt-started dbus-daemon the logfile was empty, I guess I need to recompile dbus with that enabled. I'll let you know if I figure it out. Not today though. Have a nice day, Martin
signature.asc
Description: PGP signature
