sans dbus: libsdl2 and dbus
When I upgraded to ascii, I noticed a severe performance loss in programs utilising the SDL2 library, so I used strace and found that these programs tried to read the files /etc/machine-id and /var/lib/dbus/machine-id and what really degrades program performance is that they try to execv dbus-launch over and over again. The problem with machine-id could be solved by creating a fake /etc/machine-id file and symlinking it to /var/lib/dbus/ (this also concerns programs using libgtk3 and libqt5). To relieve the second problem of tries to execv dbus-launch, I had to recompile libsd2 without dbus support.
Attached is a C source for a fake-machine-id tool, which is to be run by cron, e.g.:
*/3 * * * * umask 022; /usr/local/bin/fake-machine-id >/etc/machine-id
-
changed title from libsdl2 and dbus to sans dbus: libsdl2 and dbus
-
I notice that programs output many complaints about missing machine-id. I wondered if this might cause other issues, many thanks for confirming this.
My current solution to the dbus situation is to not point to dbus reliant programs in documentation in the future, so all future recommendations should be free of dbus. That should mean less attempts to call on dbus overall. But it seems unlikely users can avoid these issues altogether without their own builds.
Edited by dev1fanboy -
@kitootec I gave this a little more thought and was discussing it in #debianfork.
If the problem still exists, would you mind reporting it as a bug to debian? sdl really shouldn't be behaving this way just because dbus is missing. It may also be worth checking upstream to see if this problem exists. I would file this but it seems you're much more familiar with the problem than I am.
Thanks,
chillfan
-
This seems to be a Debian bug. Short of the bug being reported by the original poster, there is nothing to do in this wiki. Closing for now.
-
closed
