Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LXAppearance hangs the desktop when started from TigerVNC #202

Closed
MichaIng opened this issue Sep 11, 2020 · 2 comments
Closed

LXAppearance hangs the desktop when started from TigerVNC #202

MichaIng opened this issue Sep 11, 2020 · 2 comments

Comments

@MichaIng
Copy link

I'm not sure which component of the RPi repository makes the difference compared to Debian, so I'm reporting the following issue here:

When installing TigerVNC and LXDE on RPi with the RPi repository applied, starting LXAppearance within a VNC LXDE session hangs the whole desktop. The mouse pointer gets a loading circle, no LXAppearance appears and any desktop interaction is frozen, aside of moving the mouse cursor.

Checking processes on a second session reveals that it hangs on dbus-launch and killing this dbus-launch child makes LXAppearance appear and function normally, no further issues until it is opened again:
lxappearance

This does not happen on any other SBC or PC with Debian, not tested on RPi 64-bit OS on my end. It only happens within virtual TigerVNC desktop sessions, not RealVNC, nor local desktop.

Neither TigerVNC nor LXDE session logs show anything related, but I can of course provide logs and info if required, but I suggest to simply try to replicate on a fresh Raspberry Pi OS 32-bit Lite with the above two packages installed an simply use default setup/configs, no modifications. I think TigerVNC will invoke LXDE automatically, but in case, this is how I do currently (was playing around much, all without any effect on the issue):
cat /root/.vnc/xstartup

#!/bin/dash
exec lxsession -s LXDE -e LXDE

tigervncserver :1 -verbose

@MichaIng
Copy link
Author

MichaIng commented Sep 12, 2020

I learned that there is no interest in native LXDE support and that the LXDE packages from archive.raspberrypi.org are highly modified on different layers (LXDE-pi session with no lxappearance support at all but own appearance tool), but hopefully someone has still an idea what the issue can be here.

I tried to replicate on Raspberry Pi OS 32-bit with desktop and on regular RPi desktop as well as when manually switching session profile from LXDE-pi to LXDE, lxappearance starts, even that on LXDE-pi session its switches have no effect and chosen icon set/theme etc are not applied or selection saved.

What I see as error message:

** (lxappearance:1350): WARNING **: 19:07:57.543: lxappearance.c:67: Failed to connect to the session message bus: Failed to connect to socket /run/user/0/bus: Connection refused

The exact same shows up when installing lxde on Raspberry Pi OS Lite AFTER killing dbus-launch, so that it hangs is a difference an I try to figure out which package or config makes the difference and why on regular Debian (any other SBC or machine) this issue does not exist.

@MichaIng
Copy link
Author

Another day of testing and debugging and finally I found a solution for hanging lxappearance on TigerVNC LXDE sessions. Don't ask me for details why this is required in this specific circumstance, but apt install dbus-user-session solves the issue.

  • Basically without this package, when starting an X session, a dbus-daemon + dbus-launch instance is started with a specific ID. On lxappearance start, the exact same dbus-launch (same cmd options, same ID) is attempted to be started again, which hangs. Only a single instance is allowed, which is somewhat explained in the package details.
  • With this package, the dbus-daemon instance is started a systemd --user child process, the dbus-launch is not visible. This seems to allow the concurrent dbus-launch instance(s) then.

Here the different process hierarchy can be seen:
dbus

If someone has some deeper insights why this is required for lxappearance within TigerVNC LXDE session only, while in no other case a similar issue was observed, I would be very interested.

When I find time, I do some investigation what RealVNC virtual desktops do differently so that it is not an issue there, but for today I'm happy to have found a solution and mark this issue hence as closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant