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
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
glxgears run in the container?).xclock (plain non-OpenGL application) and see if you can replicate.xclock does not cause the issue, then try to get a reproducible scenario with glxgears.Hi,
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.
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/
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.
Sorry, I understood that wrong.
I use Void on my host and an Ubuntu 18.04 container.
LXD is on version 4.9 btw.
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.
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?
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.
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: 0I 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).
Hello! Apologies for 4 year thread revival, but I ran into this same problem and it ended up being a crazy unexpected (to me) issue where the new windows and/or popups within containers were likely triggering the host KDE environment’s kwin to make a DNS request against the lxc container name. I still don’t know why this locks up the ENTIRE system, and it took me FOREVER to hunt down. But I realized it was likely a network-based issue when I found it did NOT occur while I had one of my network interfaces unplugged. That revelation led me to find the following issue in the “toolbox” repository:
The user in that issue post solved the problem by adding “toolbox” (the container name) to the 127.0.0.1 entry in /etc/hosts on their host machine. I found that as soon as I similarly added my lxc container names to my host’s /etc/hosts file, the problem ceased immediately. I assume this could also be solved in multiple other ways via DNS routing, but this solution seemed to be the quickest, and at least proves the “source” of the issue.
This was a very frustrating bug so I wanted to still put this here to assist anyone that stumbles upon this issue (as this thread was one of the first threads I found while trying to debug this).