Intermittent Xlib error on elementary OS (XFCE)

[RedBearAK]

This is related to the stubborn Xlib error issues discussed in issue #206 where it only seemed to happen on MX Linux at the login greeter (lightdm) and when logging into IceWM, a very old, lightweight window manager, but never seemed to happen in XFCE.

I can also confirm that the Xlib error happens when logging into IceWM on Linux Mint 19.3 (32-bit) on the same old P4 laptop involved in issue #206 . But again, it doesn't occur in the default XFCE DE on Linux Mint.

Basically, upon logging into elementary OS on this new system, Kinto is (sometimes) not working, and must be restarted via systemctl.

This time it is on a completely new AMD Ryzen 5 system, built on a new Asrock B550 motherboard, 32GB of RAM and a GT710 2GB GPU. The operating system involved is elementary OS installed from the latest 5.1.5 ISO. Desktop is of course XFCE.

The occurrence of the bug seems to be hit or miss. Sometimes it happens, usually it doesn't.

I do not need to run the xhost command, unlike the situation with IceWM. But I do have to restart the xkeysnail service in the terminal to clear the Xlib error and get Kinto working.

Pretty sure it's the exact same error so I'll just paste the output from the other thread for reference:

Jun 14 20:04:14 mx-sager sudo[3590]:     current_window = display.get_input_focus().focus
Jun 14 20:04:14 mx-sager sudo[3590]:   File "/usr/local/lib/python3.7/dist-packages/Xlib/display.py", line 607, in get_input_focus
Jun 14 20:04:14 mx-sager sudo[3590]:     return request.GetInputFocus(display = self.display)
Jun 14 20:04:14 mx-sager sudo[3590]:   File "/usr/local/lib/python3.7/dist-packages/Xlib/protocol/rq.py", line 1369, in __init__
Jun 14 20:04:14 mx-sager sudo[3590]:     self.reply()
Jun 14 20:04:14 mx-sager sudo[3590]:   File "/usr/local/lib/python3.7/dist-packages/Xlib/protocol/rq.py", line 1381, in reply
Jun 14 20:04:14 mx-sager sudo[3590]:     self._display.send_and_recv(request = self._serial)
Jun 14 20:04:14 mx-sager sudo[3590]:   File "/usr/local/lib/python3.7/dist-packages/Xlib/protocol/display.py", line 586, in send_and_recv
Jun 14 20:04:14 mx-sager sudo[3590]:     raise self.socket_error
Jun 14 20:04:14 mx-sager sudo[3590]: Xlib.error.ConnectionClosedError: Display connection closed by server: [Errno 32] Broken pipe

There seems to be some sort of fundamental issue with the Xlib package code, as listed above.

Xlib/display.py", line 607, in get_input_focus
    return request.GetInputFocus(display = self.display)
Xlib/protocol/rq.py", line 1369, in __init__
    self.reply()
Xlib/protocol/rq.py", line 1381, in reply
    self._display.send_and_recv(request = self._serial)
Xlib/protocol/display.py", line 586, in send_and_recv
    raise self.socket_error
Xlib.error.ConnectionClosedError: Display connection closed by server: [Errno 32] Broken pipe

I don't have the expertise to know how to troubleshoot this.

[RedBearAK]

Confirmed that this is the same error as that observed in MX Linux with lightdm and IceWM. The only difference is eOS is using python3.6 instead of python3.7.

Also confirmed this is happening while at the greeter, before logging in to the desktop. Elementary has had some different greeters but seems to be using lightdm in this case.

Just logged out and logged back in to the eOS default desktop and once again see the Xlib error. Restarting xkeysnail.service fixes the error for this session.

Completely rebooting and logging in... Kinto works fine. No idea why this is intermittent.

Logging out and back in... once again Xlib error, Kinto not working.

[rbreaves]

The systemd service of xkeysnail is designed to load when the graphical target has been loaded, although when you log off this destroys the user level graphical target, and the service will error out, assuming the service does not properly end.

In either case it shouldn't be creating a problem, but I do believe what you are saying, I just don't know the specific cause. The other thing that is happening to ensure the service starts back up correctly when you log your user back in is the file located here.

~/.config/autostart/xkeysnail.desktop

[Desktop Entry]
Name=Kinto_xkey
GenericName=Kinto_xkey
Comment=Make Linux Type Like it's a Mac
Exec=/bin/bash -c "{xhost} +SI:localuser:root && sudo {systemctl} restart xkeysnail"
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true

You could update this line here

Exec=/bin/bash -c "{xhost} +SI:localuser:root && sudo {systemctl} restart xkeysnail"

to

Exec=/bin/bash -c "sleep 30 && {xhost} +SI:localuser:root && sudo {systemctl} restart xkeysnail"

Of course I'd continue to use the full path for sleep, xhost, and systemctl. (Use 'which sleep' etc to do that)

Also it is likely intermittent because in some cases xkeysnail.desktop must be fully running before your x11 session has fully initialized and that would be a no go.

Note: You might not need to sleep for 30 seconds, 5, or 10 may be enough. I am not sure I want to introduce this delay into the master or dev branch as it is more of work around for a problematic issue that hasn't really been occurring for me in the distros I use. I mean if nothing else I could apply certain delays to particular distros - but I would rather find a surefire way of starting the service AFTER the x11 session has begun in a systemd approved sort of way.

[RedBearAK]

Yes, I thought I would try the delay at some point, and it should work since a manual xhost command hasn't been necessary.

Thanks for pointing out exactly where to put it.

But there does seem to be some more fundamental issue happening with Xlib that the delay will just be sidestepping.

That said, I can't really see how at least adding a "sleep 5" to the main branch could really hurt anything. On most systems that should be all that would ever be necessary, and how many people would ever even try to activate a keyboard shortcut within 5 seconds of logging in? If the problem is that xkeysnail is somehow trying to activate or restart in that brief interval between being on the login screen and the desktop coming up, that typically encompasses less than 2 seconds on most modern machines.

The whole thing is weird because isn't the point of the autostart stuff that they are triggered by logging into the X session?

Obviously it would still be very desirable to have something do a better job of noticing the Xlib error and attempting to restart xkeysnail if the GUI is in fact up and running.

Anyway, going to try the delay shortly.

[RedBearAK]

Question: Is this file supposed to exist already? Because it doesn’t on my eOS machine. The only thing in there right now is a file to autostart Albert.

[RedBearAK]

Experiencing a peculiar phenomenon if I open a terminal and try to type anything prior to Kinto fixing itself (I used a 6 second window). The whole keyboard is messed up for a while. Most keys don’t type anything at all in the terminal. Even the arrow keys will type characters like “B”, “C”, and “D”, which of course makes it impossible to scroll up to a recent terminal command that might be able to fix the issue.

Usually this all gets sorted out as soon as Kinto restarts successfully, but at least once I had to log out (via mouse) and try again to get proper keyboard function back.

I have also experienced this on the MX system, I think, but it was extremely rare compared to the total number of times I’ve logged in/out and rebooted that system. Not certain whether I ever encountered this on the Raspberry Pi. But if it has anything at all to do with xkeysnail not starting up quite right it’s a pretty obnoxious side effect.

I can pretty much trigger this every time by just immediately opening a terminal from the eOS dock and trying to type anything. This is despite trimming the sleep delay down to 1-2 seconds.

Have to test more to confirm whether it always fixes itself eventually. I might have just been too impatient that one time I logged out using the mouse.

In short, it seems the delay helps but creates (temporary) problems of its own.

[rbreaves]

Question: Is this file supposed to exist already? Because it doesn’t on my eOS machine. The only thing in there right now is a file to autostart Albert.

As part of the install this occurs and I do not know of any reason why this would not be the case under eOS. This part of the install is pretty standard and universal for any install on a linux distro.

....
    yes | cp -rf ./xkeysnail-config/xkeysnail.desktop ~/.config/autostart/xkeysnail.desktop
        ....
    sed -i "s#{systemctl}#`which systemctl`#g" ~/.config/autostart/xkeysnail.desktop
    sed -i "s#{xhost}#`which xhost`#g" ~/.config/autostart/xkeysnail.desktop
.....

Even the arrow keys will type characters like “B”, “C”, and “D”, which of course makes it impossible to scroll up to a recent terminal command that might be able to fix the issue.

~Sounds like an issue with the terminal, but I have only ever heard of this occurring with editors like vi or vim. I am pretty sure it is unrelated to Kinto or xkeysnail. It is not something I recall from my time with using eOS myself.~

I see that you were saying this occurs before Kinto restarts.. well I can't say how xkeysnail may operate if it is initialized before x11 fully initializes itself. Xkeysnail was not particularly designed by the author as a systemd service - so room for improvements to make it start better or more reliably is certainly there. If you want to dig into how to make x11 user sessions a requirement/dependency for the systemd service then that would likely resolve the issue. I don't currently have the time to be chasing it down myself.

Another possible solution would be to fork xkeysnail and work on making it wait on x11 being fully initialized before it tries to start itself in the manner that it currently does.. that might avoid the necessity of fixing it in systemd and would give you the added benefit of fixing it on other OS's that are not using systemd.

https://askubuntu.com/questions/353911/hitting-arrow-keys-adds-characters-in-vi-editor

[RedBearAK]

I had a thought, and then I checked that thought. The cp command will fail if the directory you’re trying to copy into doesn’t exist.

I would have to do a new clean install of eOS to verify it, but I have a feeling that the autostart directory is not automatically created by the base eOS install. Maybe it doesn’t exist on eOS until you set something (like Albert) to start at login. I know I added the repository and installed Albert long after I installed Kinto, so the fact the the Albert file was alone in the autostart folder indicates to me that the cp command probably fails to install the xkeysnail.desktop file because the folder initially doesn’t exist.

I checked through the shell script where that command is found and saw no mention of ~/.config/autostart prior to the cp command. So the simplest solution to make this more reliable would probably be to issue a mkdir ~/.config/autostart just before that line, which should harmlessly fail if the folder already exists.

[RedBearAK]

I have absolutely no idea what I’m doing but I think I just created a branch and a pull request.

[RedBearAK]

Installing Kinto 1.1-9 of course wiped out the delay that I put in the desktop file (I was going to remove it anyway), so I spent some time rebooting and logging in/out to see of the Xlib error would come back. It hasn't, and since there is no delay I also can't trigger the weird keyboard issue when I open a terminal immediately after logging into the desktop.

So... I think the root of the issue was mainly that Kinto had failed to create the xkeysnail.desktop file and therefore Kinto wasn't being "fixed" by getting restarted when I log into the desktop from the greeter. But now with the fixed script in 1.1-9 the autotostart directory successfully gets created (I made sure to test that by renaming the original folder), and the xkeysnail.desktop file is installed, and I'm no longer having Kinto intermittently fail to work after login. As far as I know.

So I think this issue can be closed.

Good thing you didn't listen to me and put the delay in the master branch. That would have been a disaster.