Very random partial freezing issue with LXDE

HenriqueHCM · 2022-06-03 01:09:18

Good evening,

For a while now I've had this issue where my LXDE VERY randomly freezes most of its functions (but not all of them).

Further details: Most of the time, I'm actually able to go by full several days without any issue. Sometimes, the issue appears after a few hours of use. Sometimes it appears right after booting up my system. Sometimes it appears with a lot of programs open. Sometimes it appears with no programs open at all. I'm actually typing this for the second time because it appeared when I was typing this the first time.

Issue:
- Start menu button stops working;
- i3lock stops working (button works but screen lock fails);
- Keyboard stops working;
- Some apps won't open (ex: LibreOffice, TeamViewer, Zoom, ...);
- Some apps open normally (Firefox, Chrome, ...);
- Mouse works fine;
- Logout button works fine.

Workaround:
- Since the Logout button works, logging out and back in solves the issue.

Software:
Kernel 5.17.5-arch1-1
Xorg 21.1.3-6
LXDE 0.99.2-3
i3lock 2.13-1

Hardware:
HP 240 G6
Intel Core i3 6006U 2GHz
8GB RAM

I'd like to know if someone could please help me on where to find further info on what could be going on.

Thank you very much.

seth · 2022-06-03 07:10:03

i3lock stops working (button works but screen lock fails);

Does it maybe say that the keyboard cannot be grabbed?

When this happens the next time, switch to a different VT (ctrl+alt+f2 or so, if that fails it's not a keyboard grab) and there run

DISPLAY=:0 xdotool key "XF86LogGrabInfo"

This will print the active and passive grabs into the xorg log and tell you which process is grabbing the keyboard (iff)

HenriqueHCM · 2022-06-03 20:29:18

seth wrote:

i3lock stops working (button works but screen lock fails);
Does it maybe say that the keyboard cannot be grabbed?
When this happens the next time, switch to a different VT (ctrl+alt+f2 or so, if that fails it's not a keyboard grab) and there run
DISPLAY=:0 xdotool key "XF86LogGrabInfo"
This will print the active and passive grabs into the xorg log and tell you which process is grabbing the keyboard (iff)

i3lock is pretty standard, so the usual behavior is the white screen and green flashing circle when typing my password.
When I say it "fails" the usual green circle is replaced by a red circle with a "lock failed" message.

I'll try that next time I get the issue.
Till then gotta wait :-/

Thanks a lot

Last edited by HenriqueHCM (2022-06-03 20:31:00)

seth · 2022-06-04 05:39:06

When I say it "fails" the usual green circle is replaced by a red circle with a "lock failed" message.

So i3lock starts, can you still can input glyhps (segments of the circle flash up) but it's just the wrong input? Or is the circle immediately red?
Latter sounds like some key is hanging - try also

DISPLAY=:0 xev -event keyboard

on the other VT and see whether there's some spurious input.

ziomarco · 2022-06-04 13:33:45

I'm having almost the same problem!
It happens on a system updated today.
I also use lxde but other than you I don't have i3lock installed.
I have always kept a LTS kernel ready as a 'spare wheel' and today it was useful: booting with LTS kernel the problem seems gone...
could the issue be related to the last kernel?

EDIT:
the issue happened some minutes ago also using LTS kernel.... i also tried downgrading kernel with no success...

Last edited by ziomarco (2022-06-04 15:42:42)

HenriqueHCM · 2022-06-10 14:15:09

seth wrote:

When I say it "fails" the usual green circle is replaced by a red circle with a "lock failed" message.
So i3lock starts, can you still can input glyhps (segments of the circle flash up) but it's just the wrong input? Or is the circle immediately red?
Latter sounds like some key is hanging - try also
DISPLAY=:0 xev -event keyboard
on the other VT and see whether there's some spurious input.

Tried both commands and none returned anything.
By the time I got back in X to check if anything was going on the keyboard was unlocked again like nothing happened (actually that's another sympton: sometimes it just goes away).

seth · 2022-06-10 14:36:42

seth wrote:

DISPLAY=:0 xdotool key "XF86LogGrabInfo"
This will print the active and passive grabs into the xorg log and tell you which process is grabbing the keyboard (iff)

Though that doesn't match the

When I say it "fails" the usual green circle is replaced by a red circle with a "lock failed" message

But

the keyboard was unlocked again like nothing happened

has me wonder about the actual symptoms again - esp. since you suggest the VT switch cleared the problem
* is this workaround to unlock the keyboard reproducible?
* look into the xorg log about grabbed keys

HenriqueHCM · 2022-06-10 16:47:14

seth wrote:

seth wrote:
DISPLAY=:0 xdotool key "XF86LogGrabInfo"
This will print the active and passive grabs into the xorg log and tell you which process is grabbing the keyboard (iff)
Though that doesn't match the
When I say it "fails" the usual green circle is replaced by a red circle with a "lock failed" message
But
the keyboard was unlocked again like nothing happened
has me wonder about the actual symptoms again - esp. since you suggest the VT switch cleared the problem
* is this workaround to unlock the keyboard reproducible?
* look into the xorg log about grabbed keys

Actually we can't say switching consoles fixed the issue cause it could only be a coincidence.

But now I remembered another sympton which may add some further insight.
Sometimes I when the freezing comes I happen to have a LXTerminal open.
And when I try to type into LXTerminal I noticed the cursor is transparent (instead of black) which is usually the case when LXTerminal is in the background.

(not my screenshots but helps to get the idea)

https://upload.wikimedia.org/wikipedia/ … enshot.png
This is LXTerminal "normal" (not frozen)

https://i.stack.imgur.com/6r3ed.png
This is LXTerminal when on background or when freezing issue occurs.

moderator edit -- replaced oversized images with links.
Pasting pictures and code

Last edited by 2ManyDogs (2022-06-10 17:13:03)

seth · 2022-06-10 18:30:05

Actually we can't say switching consoles fixed the issue cause it could only be a coincidence.

seth wrote:

since you suggest the VT switch cleared the problem is this workaround to unlock the keyboard reproducible?

And when I try to type into LXTerminal I noticed the cursor is transparent

Means the window doesn't have/get the keyboard focus.

Arch Linux

#1 2022-06-03 01:09:18

Very random partial freezing issue with LXDE

#2 2022-06-03 07:10:03

Re: Very random partial freezing issue with LXDE

#3 2022-06-03 20:29:18

Re: Very random partial freezing issue with LXDE

#4 2022-06-04 05:39:06

Re: Very random partial freezing issue with LXDE

#5 2022-06-04 13:33:45

Re: Very random partial freezing issue with LXDE

#6 2022-06-10 14:15:09

Re: Very random partial freezing issue with LXDE

#7 2022-06-10 14:36:42

Re: Very random partial freezing issue with LXDE

#8 2022-06-10 16:47:14

Re: Very random partial freezing issue with LXDE

#9 2022-06-10 18:30:05

Re: Very random partial freezing issue with LXDE

Board footer