You are not logged in.
My initial problem after setting up Arch 3 days ago:
Krusader running as a normal user is ok, but as soon as it runs as root and you try to copy files, it fails with "Unable to create io-slave. Cannot talk to klauncher: Not connected to D-Bus server".
But according to my tests&research, this issue affects hole dbus (dbus 1.10.16-1 as distributed by the package system):
with kdesu/sudo -> error
MYUSERNAME@MYHOSTNAME:~> echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1001/bus
MYUSERNAME@MYHOSTNAME:~> qdbusviewer
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
<working dbus viewer starts, terminated by me after verifying that it works>
MYUSERNAME@MYHOSTNAME:~> kdesu konsole
QXcbConnection: XCB error: 3 (BadWindow), sequence: 777, resource id: 37749699, major code: 40 (TranslateCoords), minor code: 0
root@MYHOSTNAME:/home/MYUSERNAME> echo $DBUS_SESSION_BUS_ADDRESS
root@MYHOSTNAME:/home/MYUSERNAME> qdbusviewer
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
and qdbusviewer says:
Error: Cannot connect to D-Bus: Not connected to D-Bus server
Same issue with sudo instead of kdesu.
Possible solution #1:
kdesu with dbus-launch -> works
MYUSERNAME@MYHOSTNAME:~> kdesu dbus-launch konsole
root@MYHOSTNAME:/home/MYUSERNAME> echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-1v8lCWERxD,guid=4df8cdfa309c23f355a6097158cce8af
root@MYHOSTNAME:/home/MYUSERNAME> qdbusviewer
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
<working dbus viewer starts, terminated by me after verifying that it works>
but dbus's manpage says:
If you run dbus-launch myapp (with any other options), dbus-daemon will not exit when myapp terminates: this is because myapp is assumed to be part of a larger session, rather than a session in its own right.
Thus, this isn't a nice and clean solution.
Possible solution #2:
Apparently, I encountered this bug: https://bugs.archlinux.org/task/51026
After reading https://www.reddit.com/r/archlinux/comm … 1_support/, I decided to recompile dbus with ABS including the --enable-x11-autolaunch option.
This fixed the error above.
Possible solution #3:
Then, out of curiosity, I removed --enable-x11-autolaunch and recompiled it again. I even deleted my complete build directory and started from scratch with the PKGBUILD file from ABS.
After installing the generated package and reboot, I tried:
MYUSERNAME@MYHOSTNAME:~> echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1001/bus
MYUSERNAME@MYHOSTNAME:~> kdesu konsole
root@MYHOSTNAME:/home/MYUSERNAME> echo $DBUS_SESSION_BUS_ADDRESS
root@MYHOSTNAME:/home/MYUSERNAME> qdbusviewer
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
<working dbus viewer starts>
config.log: pastebin.com/Cayh1hbE
This also fixed the error with krusader/gedit/mousepad (mentioned in the Arch bug report above).
In summary: It doesn't matter whether dbus is compiled with --enable-x11-autolaunch or not, but the dbus package provided from the core repo (https://www.archlinux.org/packages/core/x86_64/dbus/) causes this issue, and compiling locally with the same PKGBUILD file helps. Why?
I'm new to Arch (but used to Debian/Fedora) and quite clueless regarding this issue.
Last edited by Leceaba (2017-03-19 11:06:07)
Offline
The --enable-x11-autolaunch flag doesn't make any difference, x11 support will be built if headers are present on your system. If you want to reproduce the built package in the repo, build in a clean chroot
Offline
You can also use dbus-launch --exit-with-session which will kill the root session dbus when your program exits.
Offline
Ah! An automagical build procedure...
@arojas: Thanks, that helped. At least regarding the --enable-x11-autolaunch issue all binaries behave like expected (i.e., (not) causing the dbus connection error), whereas executables (build in chroot/repo packages) still differ.
dbus doesn't support reproducible builds, after all.
see https://lists.archlinux.org/pipermail/a … 27350.html, https://tests.reproducible-builds.org/d … /dbus.html, https://www.bsdcan.org/2016/schedule/at … Builds.pdf
@V1del:
citing the manpage for the sake of completeness :-)
--exit-with-session
If this option is provided, a persistent "babysitter" process will be created, as if for --exit-with-x11. If it cannot connect to the X server,
it will monitor the terminal from which dbus-launch was started instead, and if it gets a HUP on stdin, the message bus daemon will be killed.
This option is not recommended, since it will consume input from the terminal where it was started; it is mainly provided for backwards compatibility.
Unfortunately not that elegant, too.
I think I will use my self-compiled dbus in order to circumvent this dbus connection error. In case of dbus updates I can live with recompiling.
PS: That's the guilty commit responsible for these dbus issues: https://git.archlinux.org/svntogit/pack … 9b55087b6c
edit: added link to this thread to FS#51026
Last edited by Leceaba (2017-03-19 11:44:40)
Offline