[regression] Some apps fail to start with [QPA] UbuntuClientIntegration: connection to Mir server failed.

same journalctl without apparmor ALLOWED spam

Status changed to 'Confirmed' because the bug affects multiple users.

These messages are shown in the journal:

févr. 07 09:56:04 ubuntu-Inspiron-3138 snappy-xmir[18402]: Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0'
févr. 07 09:56:04 ubuntu-Inspiron-3138 snappy-xmir[18402]: [QPA] UbuntuClientIntegration: connection to Mir server failed.
févr. 07 09:56:04 ubuntu-Inspiron-3138 snappy-xmir[18402]: Mir returned: "Failed to connect to server socket: No such file or directory"
févr. 07 09:56:04 ubuntu-Inspiron-3138 systemd[3343]: ubuntu-app-launch-application-snap-ubuntu-clock-app_ubuntu-clock-app_29-1486457714107760.service: Main process exited, code=exited, status=1/FAILURE

This is not a snap or Unity8 bug. The same platform-api apps fail with the same error under Mir demo servers too.

Also, the problem is not Mir, despite the error message.

The Mir server is not getting any connection request from the broken apps. However other apps like 'system-settings', 'dialer-app', and various mir-demos work fine still.

This is not the original issue, but yesterday I switched the unity8 snap to use a different, more standard path (/run/user/xxx/mir_socket) for the socket.

So if testing against the u8 snap, please re-create your app snaps to pull down the latest version of the desktop-launch script which will point your app at the new, correct socket location. Again, this isn't the same issue as OP, but I didn't want this new issue to confuse your testing of this bug.

I understand. Unfortunately we're hitting new launch failure bugs every few days now. So the launch failure one logged days ago might not be the same bug experienced today.

Regardless of bug status we just need to get the code back to a semi-working state where apps will actually run, and then we can clarify the bugs.

The log file makes this look like an app that is exporting the unity7 interface as well as the unity8 one. But the snapd in zesty doesn't have a unity8 interface. So we're starting it as a unity7 app. It is not realizing this and trying to connect to Mir, even after we've setup XMir for it.

Is this still happening?

Seemed to have been fixed with develop rc_proposed but then the wifi broke!

On 23 February 2017 at 15:53, Michael Terry <email address hidden>
wrote:

> Is this still happening?
>
> --
> You received this bug notification because you are subscribed to Ubuntu
> Touch Developer Preview.
> Matching subscriptions: <email address hidden>
> https://bugs.launchpad.net/bugs/1662145
>
> Title:
> [regression] Some apps fail to start with [QPA]
> UbuntuClientIntegration: connection to Mir server failed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1662145/+
> subscriptions
>

--
*Andy Bleaden*
07946481674
Skype/Twitter/Telegram *@andybleaden*

Further to comment #12, I've noticed in a few other bug reports people are experiencing rendering glitches in Qt apps that should only happen with Xmir. So we seem to have a problem with our own Qt apps incorrectly choosing X(mir) when native Mir is available and should be used instead.

Daniel, that may be because now we choose whether to use xmir or not based on the presence of the 'mir' interface (used to be the 'unity8' interface). Not all apps may plug into that interface.

Sure, it's important to offer both X and Mir sockets to all apps.

Also very important that those apps (toolkits) choose native Mir over X when both are available.

Agreed. I was just trying to highlight that an app that used to work as Mir might now be run under XMir because we switched which interface we look at.

Does that mean that apps that plug to the "unity8" iface should be updated to plug to "mir" now?

They should add mir, yeah. No need to replace unity8, necessarily [1].

[1] For the moment, plugging unity8 will make you uninstallable. This is to prevent widespread use of that interface before we finish it. The default set of core apps have an exception to this, though.

> Also very important that those apps (toolkits) choose native Mir over
> X when both are available.
Qt isn't designed to make the choice itself, it expects to be told if either X or Mir should be used.