UI (XFCE) freezes occasionally with a STOP signal

cherio · 2025-10-24 21:39:10

Once in a blue moon my XFCE desktop freezes. The first time it occurred I switching to another TTY and determined that a bunch of UI processes were running with "T" status, as if they were sent a "STOP" signal. This happens in the middle of me doing something (e.g. switching to another window, clicking on something etc), not related to "suspend"/"resume"/screen lock etc. This is a 24/7 workstation that doesn't hibernate or suspend.

Up until recently the solution (not really a solution) was to send a "CONT" signal to all of them, which unfreezes the UI. I even saved a short script implementing this logic that I run from another TTY a dozen of times in a tight loop, just to make sure:

ps -u userjohn -Ao pid,stat | grep -Po '\d+(?= T)' | xargs -r kill -s CONT

The last time this happened the script didn't help. Something was re-sending the "STOP" signal almost immediately. I had to "CONT"+"TERM" them.

I'd like to find the culprit but I'm not sure how to approach it. This happens infrequently, e.g. once a month so I can't afford just waiting for it to happen or run the system with a resource consuming debug/watch logging every event or signal. journalctl doesn't seem to have any relevant information in it at the time of the freeze.

My usual suspects are either google-chrome or vscode, but I have no proof.

Any ideas of how to catch the culprit red-handed would be appreciated!

unixman · 2025-10-25 05:41:15

disclaimer: this is pure speculation

Since it is a 7/24 workstation and not reboot for mounts/years;
Therefore it is care of "resources" a little much.

When that UI guys starts to burden a little as memory hog or CPU load
systemd is noticed and send signal to them.
systemd sees them as unimportant side services.

Or is that UI guys 7/24 too?
How about memory leak or some ulimit reached?

increase journald debug level to 'debug'; thats may help.

seth · 2025-10-25 08:47:05

How do you start the session? startx? startxfce4?
And how do you start the "usual suspects"?

This usually happens when a signal (SIGHUP?) leaks to the parenting shell that then stops the entire group.

cherio · 2025-10-25 16:48:34

seth wrote:

How do you start the session? startx? startxfce4?
And how do you start the "usual suspects"?

Your 6th sense in this always amuses me.

I run startx from TTY with "~/.xinitrc" being a copy of /etc/X11/xinit/xinitrc with the final "twm" and "exec" calls replaced with "startxfce4"

chrome is launched via a XFCE keyboard shortcut while `vscode` is launched from `thunar` custom action.

seth wrote:

This usually happens when a signal (SIGHUP?) leaks to the parenting shell that then stops the entire group.

Huh. Unfortunately I didn't save the list of processes with "T" status but I believe I saw Xorg had "T" status set as well when it happened.

Is there a connection between how I start the session and the potential for SIGHUP leaking?
Should I run "startxfce4" via "nohup"?
Would it be prudent to configure launching chrome and vscode via "nohup"?

unixman wrote:

Since it is a 7/24 workstation and not reboot for mounts/years

This is not an issue. I typically update+reboot on weekends, and sometimes during the week.

seth · 2025-10-25 17:42:57

I see dead processes…

I'd try to cut out startx first, just run "xinit" - you might have to adjust the xserverrc: https://wiki.archlinux.org/title/Xinit# … nal_number

Alternatively remove your xinitrc and just run "startxfce4" instead (it'll xinit itself)
If you're indeed still running into this, "nohup startxfce4" would be a good next test.

Arch Linux

#1 2025-10-24 21:39:10

UI (XFCE) freezes occasionally with a STOP signal

#2 2025-10-25 05:41:15

Re: UI (XFCE) freezes occasionally with a STOP signal

#3 2025-10-25 08:47:05

Re: UI (XFCE) freezes occasionally with a STOP signal

#4 2025-10-25 16:48:34

Re: UI (XFCE) freezes occasionally with a STOP signal

#5 2025-10-25 17:42:57

Re: UI (XFCE) freezes occasionally with a STOP signal

Board footer