[Interest] "Dynamic session lookup supported but failed"

Post by RenÃ© J.V. Bertin
Hi,
I'm seeing this message printed on my terminal when I start Qt5 applications
Dynamic session lookup supported but failed: launchd did not provide a
socket path, verify that org.freedesktop.dbus-session.plist is loaded!

This means you used QtDBus, which tried to connect to the bus daemon, which
was compiled with support for launchd but the .plist file wasn't loaded into
launchd.

Post by RenÃ© J.V. Bertin
Before I start hunting that string down in the Qt source code: is there a
way for an application to indicate that it has no business with the DBus or
any other kind of session lookup?

No. If you use the D-Bus session bus, it will try to connect. There's no way
to force it to fail (outside of unit tests).

Post by RenÃ© J.V. Bertin
If not: does Qt use DBus/"dynamic session
lookup" behind the scenes to implement certain functionality that the user
might miss even in a purely standalone application?

Yes. It requires loading the .plist file into launchd.

But since Qt doesn't ship with the daemon, the D-Bus libraries or the .plist
file, the problem here is that your system *does* have them but didn't configure
them. Why do you have the D-Bus library somewhere that QtDBus could find it but
didn't configure it properly?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

René J.V. Bertin

2015-05-15 18:57:31 UTC

Post by Thiago Macieira
This means you used QtDBus, which tried to connect to the bus daemon, which
was compiled with support for launchd but the .plist file wasn't loaded into
launchd.

I don't use it, not explicitly at least. Does Assistant use QtDBus, for instance?

Post by Thiago Macieira
But since Qt doesn't ship with the daemon, the D-Bus libraries or the .plist
file, the problem here is that your system *does* have them but didn't configure

This isn't (entirely) true. I indeed have DBus installed, and also running on my "console" session, so that for instance KMail (which I'm typing in right now) works.

Post by Thiago Macieira
them. Why do you have the D-Bus library somewhere that QtDBus could find it but
didn't configure it properly?

The exact same way a similar situation can arise on Linux: logging in remotely over SSH without starting a dedicated session DBus and starting an application to display remotely using the xcb plugin. On Linux you'll also get an error when you don't have a launched that session DBus, but only when the application actually tries to connect to it. You don't get that error with Assistant for instance.

AFAIK, it is not possible to launch multiple session DBuses with the OS X implementation. That should be fine as long as you don't actually use it, and it would be nice if there were only an error message when an attempt is made to use DBus functionality.

NB: when I login over SSH I can start Qt applications for local display (on the "console", regardless of who is logged in there (*)), and then there is no error message. Yet `launchctl export` doesn't show me the DBUS socket variable that it shows from a local shell.

*) I've reported that as a bug, because a remotely logged in user B should not be able to open applications on/in the local session of a user A.

I hope this made it a bit clearer...

R.

Thiago Macieira

2015-05-15 19:22:05 UTC

Post by Thiago Macieira
This means you used QtDBus, which tried to connect to the bus daemon, which
was compiled with support for launchd but the .plist file wasn't loaded
into launchd.

I don't use it, not explicitly at least. Does Assistant use QtDBus, for instance?

Nothing in cross-platform Qt should be using it directly. The only thing that
uses QtDBus directly is the XCB platform plugin (for the D-Bus menu and app
indicators).

Put a breakpoint in dbus_bus_get and dbus_bus_get_private and see where they
got called from.

Post by Thiago Macieira
But since Qt doesn't ship with the daemon, the D-Bus libraries or the
.plist file, the problem here is that your system *does* have them but
didn't configure

This isn't (entirely) true. I indeed have DBus installed, and also running
on my "console" session, so that for instance KMail (which I'm typing in
right now) works.

How did you start the daemon for that session?

Post by Thiago Macieira
them. Why do you have the D-Bus library somewhere that QtDBus could find
it but didn't configure it properly?

Correct, it will complain that it can't autostart because you've got no X
connection. If you did (ssh -X), then it would autostart without complaining.

This is expected behaviour.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

René J.V. Bertin

2015-05-15 20:09:48 UTC

Post by Thiago Macieira
Nothing in cross-platform Qt should be using it directly. The only thing that
uses QtDBus directly is the XCB platform plugin (for the D-Bus menu and app
indicators).

But that is the platform plugin used on Linux, and yet it doesn't complain when I start, say, Assistant without a session DBus?

Post by Thiago Macieira
Put a breakpoint in dbus_bus_get and dbus_bus_get_private and see where they
got called from.

dbus_bus_get doesn't get called, but:

* thread #1: tid = 0x39cdb1, 0x000000010849df19 libdbus-1.3.dylib`dbus_bus_get_private, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x000000010849df19 libdbus-1.3.dylib`dbus_bus_get_private
frame #1: 0x0000000104e719e5 QtDBus`QDBusConnection::connectToBus(QDBusConnection::BusType, QString const&) [inlined] q_dbus_bus_get_private(type=<unavailable>, error=0x0000000000000000) + 8 at qdbus_symbols_p.h:98
frame #2: 0x0000000104e719dd QtDBus`QDBusConnection::connectToBus(type=<unavailable>, name=<unavailable>) + 365 at qdbusconnection.cpp:334
frame #3: 0x0000000104e73b66 QtDBus`QDBusConnection::sessionBus() [inlined] QDBusDefaultConnection::QDBusDefaultConnection(type=<unavailable>) + 39 at qdbusconnection.cpp:1054
frame #4: 0x0000000104e73b3f QtDBus`QDBusConnection::sessionBus() [inlined] QDBusDefaultConnection::QDBusDefaultConnection(type=<unavailable>, newValue=<unavailable>) at qdbusconnection.cpp:1064
frame #5: 0x0000000104e73b3f QtDBus`QDBusConnection::sessionBus() [inlined] (anonymous namespace)::Q_QGS__q_sessionBus::innerFunction() + 41 at qdbusconnection.cpp:1070
frame #6: 0x0000000104e73b16 QtDBus`QDBusConnection::sessionBus() [inlined] QGlobalStatic<QDBusDefaultConnection, (anonymous namespace)::Q_QGS__q_sessionBus::innerFunction(), (anonymous namespace)::Q_QGS__q_sessionBus::guard>::operator()() at qglobalstatic.h:129
frame #7: 0x0000000104e73b16 QtDBus`QDBusConnection::sessionBus() + 70 at qdbusconnection.cpp:1084
frame #8: 0x0000000104cfb003 libqxcb.dylib`DBusConnection::DBusConnection(this=0x0000000104b0d330, parent=<unavailable>) + 131 at dbusconnection.cpp:61
frame #9: 0x0000000104cf0d2d libqxcb.dylib`QSpiAccessibleBridge::QSpiAccessibleBridge() [inlined] QSpiAccessibleBridge::QSpiAccessibleBridge(this=0x0000000104b0d360) + 78 at bridge.cpp:59
frame #10: 0x0000000104cf0cdf libqxcb.dylib`QSpiAccessibleBridge::QSpiAccessibleBridge(this=0x0000000104b0d360) + 15 at bridge.cpp:61
frame #11: 0x0000000104c98ac8 libqxcb.dylib`QXcbIntegration::accessibility(this=0x0000000104a0ae50) const + 40 at qxcbintegration.cpp:385
frame #12: 0x00000001008e6586 QtGui`QAccessible::updateAccessibility(QAccessibleEvent*) [inlined] platformAccessibility() + 38 at qaccessible.cpp:482
frame #13: 0x00000001008e656d QtGui`QAccessible::updateAccessibility(QAccessibleEvent*) [inlined] QAccessible::isActive() at qaccessible.cpp:793
frame #14: 0x00000001008e656d QtGui`QAccessible::updateAccessibility(event=0x00007fff5fbfeb70) + 13 at qaccessible.cpp:863
frame #15: 0x000000010019c016 QtWidgets`QLabel::setText(this=<unavailable>, text=<unavailable>) + 486 at qlabel.cpp:314
frame #16: 0x0000000100004839 fontweightissue`Dialog::Dialog(QWidget*) + 2025
frame #17: 0x000000010000c534 fontweightissue`main + 484
frame #18: 0x0000000100003bf4 fontweightissue`start + 52

The error message gets printed while stepping out of dbus_bus_get_private.

Post by Thiago Macieira
How did you start the daemon for that session?

It gets started automatically through launchd.

Post by Thiago Macieira
Correct, it will complain that it can't autostart because you've got no X

What is "it" here?

Post by Thiago Macieira
connection. If you did (ssh -X), then it would autostart without complaining.

Hmm, I usually do ssh -X or I set DISPLAY manually to avoid ssh tunnelling, and never get an automatic DBus launch when logged in remotely. Are you sure that autostart is done on all Linux distributions, regardless of the shell you use?
(I don't think ssh -X actually sets up an X connection other than for the auth handshake?)
Or is it a feature introduced in Qt 5.4?

Either way, DBus on OS X doesn't look at X connections, to my knowledge.

Post by Thiago Macieira
This is expected behaviour.

Yes, and appreciated when the absence of a DBus session impairs application functionality ... otherwise it's a bit like complaining about the fly being open on a pair of trousers I'm not wearing ;)

R.

Thiago Macieira

2015-05-15 20:30:54 UTC

Post by Thiago Macieira
Nothing in cross-platform Qt should be using it directly. The only thing
that uses QtDBus directly is the XCB platform plugin (for the D-Bus menu
and app indicators).

But that is the platform plugin used on Linux, and yet it doesn't complain
when I start, say, Assistant without a session DBus?

By "without a session", do you mean in SSH without -X? Why would you want to
run a graphical application without a graphical server?

Post by Thiago Macieira
Put a breakpoint in dbus_bus_get and dbus_bus_get_private and see where
they got called from.

[cut]
frame #7: 0x0000000104e73b16 QtDBus`QDBusConnection::sessionBus() + 70 at
qdbusconnection.cpp:1084
frame #8: 0x0000000104cfb003
libqxcb.dylib`DBusConnection::DBusConnection(this=0x0000000104b0d330,
parent=<unavailable>) + 131 at dbusconnection.cpp:61

You're using XCB. It expects X behaviour.

Post by Thiago Macieira
How did you start the daemon for that session?

It gets started automatically through launchd.

Post by Thiago Macieira
Correct, it will complain that it can't autostart because you've got no X

What is "it" here?

I was wrong. It would have complained if you had no X.

The problem here is that you *do* have X, so it didn't complain because it
found the session bus.

Post by RenÃ© J.V. Bertin
Hmm, I usually do ssh -X or I set DISPLAY manually to avoid ssh tunnelling,
and never get an automatic DBus launch when logged in remotely. Are you
sure that autostart is done on all Linux distributions, regardless of the
shell you use?

Yes. It's implemented inside dbus_bus_get_private, like you've just noticed.
It is not dependent on the shell you use.

Post by RenÃ© J.V. Bertin
(I don't think ssh -X actually sets up an X connection other
than for the auth handshake?)

It sets up a tunnel, which results in the same thing.

Post by RenÃ© J.V. Bertin
Or is it a feature introduced in Qt 5.4?

No, X11 autostart is a feature I introduced some time in 2006 in D-Bus.
Probably version 0.62 or 0.90.

OS X autostart was introduced a year or two later, by one of the early KDE-on-
Mac maintainers.

Post by RenÃ© J.V. Bertin
Either way, DBus on OS X doesn't look at X connections, to my knowledge.

Correct.

The mismatch here is that your D-Bus is looking at the Aqua connection, while
your Qt is looking at the X connection. You're seeing the problem because X is
working but Aqua isn't, under your SSH connection.

Other people haven't noticed this problem because they either get both
successful or both failing. If the display connection isn't working, then you
won't see the D-Bus error anyway.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

René J.V. Bertin

2015-05-15 21:34:09 UTC

Post by RenÃ© J.V. Bertin
But that is the platform plugin used on Linux, and yet it doesn't complain
when I start, say, Assistant without a session DBus?

By "without a session", do you mean in SSH without -X? Why would you want to
run a graphical application without a graphical server?

I said "without a session DBUS". That's not the same thing. That just means that no dbus daemon was started to serve the current session.
And again, you can SSH in without -X and then set DISPLAY to the direct address of your screen, just like one did in the telnet days. As long as DISPLAY is set to a valid X server, graphical applications will run.

Post by Thiago Macieira
libqxcb.dylib`DBusConnection::DBusConnection(this=0x0000000104b0d330,
parent=<unavailable>) + 131 at dbusconnection.cpp:61
You're using XCB. It expects X behaviour.

Yes, I am. But X and DBus are 2 separate things. If it were "X behaviour" to have a session DBus when starting an application, I should see the error under Linux too when there is no session DBus.

Post by RenÃ© J.V. Bertin
What is "it" here?

I was wrong. It would have complained if you had no X.
The problem here is that you *do* have X, so it didn't complain because it
found the session bus.

Again, what is "it"? And once more, there is no session bus to be found in the context I'm talking about ...

Post by Thiago Macieira
No, X11 autostart is a feature I introduced some time in 2006 in D-Bus.
Probably version 0.62 or 0.90.

In the Qt interface to DBus I presume? The dbus-daemon process that provides the actual DBus cannot start itself after all...
What I don't understand then is why KDE4 and KF5 applications (from Ubuntu 14.04) complain about a missing dbus when I launch them over ssh, and tell me to do `eval dbus-launch` by hand.

Post by Thiago Macieira
OS X autostart was introduced a year or two later, by one of the early KDE-on-
Mac maintainers.

Post by RenÃ© J.V. Bertin
Either way, DBus on OS X doesn't look at X connections, to my knowledge.

Hmmm, so what you're saying is that QtDBus tries to create a DBus session, and then prints an error message that suggests it only tried to find an existing session? And that I don't get the error when I launch the same application under SSH on a Linux box because a DBus session is created silently and successfully (and aborted when I stop the application)?

Post by Thiago Macieira
Other people haven't noticed this problem because they either get both
successful or both failing.

Actually, I think very few people have tried to use the xcb plugin on OS X, and Qt4 hasn't built for X11 on OS X since quite a few (minor) versions (MacPorts says 4.4.3 but I think Fink has a somewhat later version).

Post by Thiago Macieira
If the display connection isn't working, then you
won't see the D-Bus error anyway.

With Aqua, with X it's another matter. The (remote) terminal is independent from the display connection.
Which makes me realise: when I mention ssh connections/sessions, I mean that I type `slogin [-X] host` or `ssh -Xf host command` in a terminal. Not something involving a remote graphical login screen taking over my whole local X server ...

R.

Thiago Macieira

2015-05-16 00:11:02 UTC

Post by Thiago Macieira
You're using XCB. It expects X behaviour.

Yes, I am. But X and DBus are 2 separate things. If it were "X behaviour" to
have a session DBus when starting an application, I should see the error
under Linux too when there is no session DBus.

The difference is D-Bus itself, not Qt and not X.

Post by RenÃ© J.V. Bertin
What is "it" here?

I was wrong. It would have complained if you had no X.
The problem here is that you *do* have X, so it didn't complain because it
found the session bus.

Again, what is "it"? And once more, there is no session bus to be found in
the context I'm talking about ...

D-Bus didn't complain.

Post by Thiago Macieira
No, X11 autostart is a feature I introduced some time in 2006 in D-Bus.
Probably version 0.62 or 0.90.

In the Qt interface to DBus I presume?

No, inside D-Bus.

D-Bus is composed of two pieces: a daemon and the client library in each
application. The libdbus-1 library that QtDBus uses does start dbus-daemon as
needed. Even without libdbus-1, QtDBus would have to do it because
autostarting the daemon is part of the specification.

Post by RenÃ© J.V. Bertin
What I don't understand then is why KDE4 and KF5 applications (from Ubuntu
14.04) complain about a missing dbus when I launch them over ssh, and tell
me to do `eval dbus-launch` by hand.

They should only do that if DISPLAY is also unset. If DISPLAY is set and
valid, then autostarting works and the applications should not tell you
anything.

Post by Thiago Macieira
The mismatch here is that your D-Bus is looking at the Aqua connection,
while your Qt is looking at the X connection. You're seeing the problem
because X is working but Aqua isn't, under your SSH connection.

Hmmm, so what you're saying is that QtDBus tries to create a DBus session,
and then prints an error message that suggests it only tried to find an
existing session?

Yes.

Post by RenÃ© J.V. Bertin
And that I don't get the error when I launch the same
application under SSH on a Linux box because a DBus session is created
silently and successfully (and aborted when I stop the application)?

Yes (no - it keeps running until the X connection closes).

Post by Thiago Macieira
Other people haven't noticed this problem because they either get both
successful or both failing.

Actually, I think very few people have tried to use the xcb plugin on OS X,

Right, they try the xcb plugin on X and they try the cocoa plugin on OS X.

Post by RenÃ© J.V. Bertin
and Qt4 hasn't built for X11 on OS X since quite a few (minor) versions
(MacPorts says 4.4.3 but I think Fink has a somewhat later version).

Qt 4 also did not support D-Bus menu, D-Bus app indicator and D-Bus-based AT-
SPI accessibility support.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

René J.V. Bertin

2015-05-17 15:59:58 UTC

They should only do that if DISPLAY is also unset. If DISPLAY is set and
valid, then autostarting works and the applications should not tell you
anything.

Apparently that's only theory, or something is wrong (different) with Kubuntu in that aspect. KDE4 and KF5 (built against Qt 5.3.2) applications complain about a missing DBus if it's not running even when DISPLAY is perfectly valid. Pure Qt (5.3.2) applications neither complain nor launch a DBus daemon.

TBH, it kind of makes sense to me not to autostart a daemon that should set env. variables in a context where it cannot set those variables. Suppose it gets started, and then the user launches another app that also requires a session DBus. If usually it would find the correct dbus-daemon with the help of an env. variable (DBUS_SESSION_BUS_ADDRESS and/or DBUS_SESSION_BUS_PID), what is it going to do when that variable isn't set? Launch another daemon, which might cause all kinds of side-effects?

R

Thiago Macieira

2015-05-17 19:05:36 UTC