X11 freezes for a few seconds in LXD container

LXD
#1

Hello everyone,

I followed @simos guide and it worked quite well.

However, when a new window or menu is opened the X server freezes for a few seconds and I can’t do anything. I switched to a different tty while that happened and ran htop. The system is still usable and not even any CPU is outlasted that much, only X hangs up for a while.

Has anyone any ideas what the cause for this could be and how to fix it?

Best regards

#2

Hi!

The possible areas to look for, are the X11 proxy device where a new X11 application in the container will create a new connection to the host’s X11 server. And also whether the issue is related to OpenGL or it appears with just plain X11 applications.

Therefore, can you find a minimal reproducible scenario that demonstrates the issue?

Note that

  1. Mention which Linux distribution runs on the host and which on in the container.
  2. Which GPU is shared to the container and whether you have enabled OpenGL (does glxgears run in the container?).
  3. Try with multiple xclock (plain non-OpenGL application) and see if you can replicate.
  4. If xclock does not cause the issue, then try to get a reproducible scenario with glxgears.
#3

Hi,

  1. I am using Void Linux
  2. glxgears works and in glxinfo I have:
    Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel® HD Graphics 620 (KBL GT2) (0x5916)
    Version: 20.0.8
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
  3. xclock causes the hang up reliably everytime it is closed
  4. glxgears doesn’t seem to be affected
#4

It is strange that xclock causes an issue but glxgears (or any other OpenGL app) does not. I would expect either both or just glxgears to have this issue.

I cannot replicate on Ubuntu host and Ubuntu container.
I run the following, while at the same time Firefox (on the host) was playing a video. I did not notice any audio/video glitch, or general unresponsiveness on the desktop.

$ lxc ubuntu steam
ubuntu@steam:~$ xclock
<click on `x` to close the application>
ubuntu@steam:~$

You may have noticed that the instructions do not mention .Xauthority, which normally would be required for some other application (running in the container) to access the host’s X server. Perhaps Void Linux has an issue here? But still, you mention the issue is on closing the application, not starting it.

#5

I allow access to the X server via xhost. It’s strange that here it only happens when it’s closed, but with some other GUIs (like qalculate, Android Studio) it happens also during use. I also happened to have firefox (on the host) running.

There is a container image of Void Linux available.
https://us.images.linuxcontainers.org/

#6

Do you use Void Linux on the host? It is a bit involved for me to switch the OS of the host.

If you get the same issue when the host is Ubuntu, then it would be easy for me to test, simply by launching a Void Linux container on my Ubuntu host.

#7

Sorry, I understood that wrong.
I use Void on my host and an Ubuntu 18.04 container.
LXD is on version 4.9 btw.

#8

Is that from the snap package?

I can only suggest to have a look at /var/snap/lxd/common/lxd/logs/mycontainer/ which has logs pertaining to your container. There are separate log files for the LXD sockets, therefore check the proxy.X0.log for any hints.

You can have top or htop running in a terminal window, so that when you get this freezing, you can get a hint whether it is due to a forkproxy process (relates to the LXD proxy devices). You should see momentarily a process with very high load.
If you do not see a process with very high load, then the freezing would likely be some I/O issue; some resource becomes unavailable, it blocks the whole system until it becomes available again.

#9

snap is not used on Void Linux.
I found proxy.X0.log in /var/log/lxd/dev/proxy.X0.log and it only contains the line Status: Started .

I tried running htop in tty1 and cause a freeze with xclock, but the forkproxy process doesn’t seem to produce any high load. Do have any guesses what kind of resource I should watch out for?

#10

This indicates that there is no discerning issue with the proxy device (Unix socket).

It looks like the short freeze is not CPU-bound but IO-bound. Check the host’s X.org logs.

#11

I monitored the Xorg logs with tail, but during and after the freeze nothing was written to it. I also checked the log of the xsession and the only new log entries I got were these:

qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 39036, resource id: 123732553, major code: 15 (QueryTree), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 41492, resource id: 25988548, major code: 3 (GetWindowAttributes), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 41493, resource id: 25988548, major code: 14 (GetGeometry), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50009, resource id: 136315091, major code: 18 (ChangeProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50125, resource id: 44045666, major code: 18 (ChangeProperty), minor code: 0
#12

I work around the issue by using Xephyr (and installing and running openbox inside the container).
The freeze doesn’t appear anymore, but I am still wondering what the cause was (maybe KDE or the proxy socket? idk).

https://wiki.archlinux.org/index.php/Xephyr