"Cannot find the D-Bus session server" for konsole + cygwin x-server

[rowbearto]

I have a test script that I run in the process buffer that launches konsole windows (and other apps run in these konsoles) on CentOS 7 x64.

This works no problem when in a VNC session and I launch konsole windows from the process buffer.

However, if I am using the cygwin X-server, login via cygwin ssh, tunnel my DISPLAY, run SE in the x-server, then try to launch konsole, I get errors:

Code: [Select]

unnamed app(2787): KUniqueApplication: Cannot find the D-Bus session server:  "Address does not contain a colon"
unnamed app(2786): KUniqueApplication: Pipe closed unexpectedly.
But I get no such error launching konsole outside of SE from my cygwin window (that is sshed in and tunneled DISPLAY).

I found a workaround, if I unset the "DBUS_SESSION_BUS_ADDRESS", then I can launch konsole from the SE process buffer.

Below is a log demonstrating this:

Code: [Select]

# Try to launch konsole from SE's secsh, get error
[SE rbresali@pss196-255 wrap]$ konsole
unnamed app(2725): KUniqueApplication: Cannot find the D-Bus session server:  "Address does not contain a colon"
unnamed app(2724): KUniqueApplication: Pipe closed unexpectedly.

# Switch to ksh, just because I know how to unset envs there
[SE rbresali@pss196-255 wrap]$ ksh -i
Inside setupEnv
[rbresali-automation] pss196-255:/home/rbresali/public_html/logs/ne_pss8_AHPHG/171130_115437_Thu-ne/wrap
$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=abstract=/tmp/none-such-31534
[rbresali-automation] pss196-255:/home/rbresali/public_html/logs/ne_pss8_AHPHG/171130_115437_Thu-ne/wrap
$ konsole
unnamed app(2787): KUniqueApplication: Cannot find the D-Bus session server:  "Address does not contain a colon"
unnamed app(2786): KUniqueApplication: Pipe closed unexpectedly.

[rbresali-automation] pss196-255:/home/rbresali/public_html/logs/ne_pss8_AHPHG/171130_115437_Thu-ne/wrap
$ unset DBUS_SESSION_BUS_ADDRESS
[rbresali-automation] pss196-255:/home/rbresali/public_html/logs/ne_pss8_AHPHG/171130_115437_Thu-ne/wrap
$ konsole

# konsole launched successfully
[rbresali-automation] pss196-255:/home/rbresali/public_html/logs/ne_pss8_AHPHG/171130_115437_Thu-ne/wrap
$ Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon

# The above error messages seem benign, konsole is running.
Any idea what is going on here?

Can I safely unset DBUS_SESSION_BUS_ADDRESS, or is there a better solution?

I don't really understand what DBUS_SESSION_BUS_ADDRESS is.

[patrick]

Is that DBUS_SESSION_BUS_ADDRESS for real?  I ask because it looks like a fake address we have recommended as a workaround in certain situations where you need to run SlickEdit where there's no dbus session running, except for the missing colon.   

I think in this case there's no problem with clearing that environment variable.  Normally that gets set up by your login session.  If we can't connect to the dbus, then Input Method Extensions for languages with large character sets won't work, and I think some of the printer support will not be available. Otherwise, you should be fine. 

[rowbearto]

I don't know exactly what you are asking for by saying "Is that DBUS_SESSION_BUS_ADDRESS for real?" If you mean do I observe it, yes I do. But I have no idea how it got there. I am using the special memory leak fix version of 22.0.0.9 if that helps.

When I ssh in from my cygwin window, at the ksh prompt DBUS_SESSION_BUS_ADDRESS is not set at all.

Then when I launch a konsole from cygwin, inside the konsole the DBUS_SESSION_BUS_ADDRESS is not set.

It is only when I run in SE where it is getting set to this strange value. I'd rather not SE set it at all, so that I don't need to unset it. Is there a way to get SE to not set it?

[patrick]

Hmm, we are setting that in the vs script.  There's a problem where Qt won't initialize on some setups when that environment variable is unset, so we're setting it to something that was (in theory) safe.  The version of konsole I have on my system doesn't choke on it, but I still need to double check we're not doing something wrong syntax-wise.

I'm not sure why your login session via SSH doesn't have a dbus session, but you can use 'dbus-launch' to start one for SlickEdit, which should sidestep this problem.  So you'd start SlickEdit like this: dbus-launch /opt/SlickEditPath/bin/vs 

Sorry for the confusion; I knew that path sounded familiar, but I didn't grep the script when checking the source for it.

[rowbearto]

Adding "dbus-launch" to my script which launches vs is working well - in both the VNC and ssh environments.

Thanks,
Rob