Getting out of a stuck desktop

If it's not possible to open a graphical terminal window, then first Ctrl-Alt-F1 to switch out of X and then execute the command. Switching back to X depends on how many terminal instances are running, if one then Ctrl-Alt-F2, if more then Ctrl-Alt-F[something] (work your way through them all).

If you're running Wayland instead of X, then I've got no idea.

Is this a Pi running with a local display and keyboard etc.? If so then doesn't CTRL+ALT+Fn (where n is 1 to 6) get you to a console login which would enable you to log in to a command line and kill chrome (or even the GUI).

Alternatively if you have remote access to the Pi then ssh to a command line and kill chrome.

Ctrl-Alt-Backspace to kill/restart the xserver is another. I have had occasions where nothing seemed to work, usually associated with networking issues.

Hasn't that been disabled by default for years on most distros?

Dunno. Works for me on Mint Mate

If you can't get a terminal window open (that happens to my Debian tower sometimes when my display driver hangs), you can ssh into the box from another machine and do the kill that way. Worst case, you can force a reboot and get an orderly shutdown.

At the risk of thread drift, why did you stop using Seamonkey? I'm using it because Firefox changed the user interface in ways I didn't like starting in release 29. But there are a small but increasing number of web sites that Seamonkey can't handle, so I have to fall back to Firefox for them.

Worse than that, clicking on an existing terminal window didn't grant it focus. I'd forgotten (again) about ctrl-alt-Fn and will try that next time the machine gets stuck, but when it happened again this morning I did check the caps lock LED and it doesn't react to the caps lock key, so it looks like the keyboard isn't being read even though the mouse still tracked.

In normal operation there are close to a dozen terminal sessions, five or six windows with a few tabs each. I've seen no indication the machine is low on resources. It's an 8 GB Pi4, could that be too much for it? I've never noticed the machine swapping, ever. I just noticed I haven't set up a hardware swap partition, so all it has is the 100 MB swapfile set up in the image file.

I'm running whatever is default for 64 bit RasPiOS. Is there some way to check if Wayland's in use?

Thanks for writing!

bob prohaska

Unless its a 4GB or more RPi 4B, it's probably running out of memory and hitting the brick wall of swapping to the SD card. It might take a couple of minutes to become responsive enough again for you to close tabs or quit the browser completely. > Is there any way to kill Chrome _other_ than power cycling?

You could try ssh'ing in to kill the browser remotely, but when swapping the ssh client will probably timeout, or be unusably slow.

You could set up the hardware watchdog to automatically reboot the machine after it has become unresponsive, but that's probably not hat you want when using it interactively.

---druck

Doesn't sound good, but it depends on how the drivers are set up. Also Ctrl-Alt-Backspace is the common command to close X entirely and return to the terminal, so you might as well try that as well if ctrl-alt-Fn doesn't work for you.

I'd guess some sort of bug in the GPU driver is bing triggered, or maybe the GPU itself in your Pi4 is getting flaky.

Check "ps -A | grep Xorg" returns a match, or run "xdpyinfo" in a graphical terminal window and see if it spits out lots of info. I don't think Wayland would be default though, so X should be a safe assumption.

On 5 Apr 2023 09:24:04 +1000, snipped-for-privacy@telling.you.invalid (Computer Nerd Kev) declaimed the following:

If the Pi is running a compress-to-RAM swap setup, there is a possibility of the compressed swap getting deadlocked.

Some years ago, I discovered that Tiny Core Linux (runs with compress-to-RAM swap) would deadlock during periods of full-out disk traffic on a high-end server with tons of RAM (for the time). Disabling the compress-to-RAM swap thing cured that. (I might have been able to solve it by setting swappiness to _never_ swap, but it was easier to just disable the swap setup entirely.)

HTH

Good point, I've tried zram swap back when I was trying to web browse on a 1GB 3B+, and had it unrecoverably hang a few times.

When I got the 4GB and then 8GB 4B's I disabled it and set up physical swap on an SSD. That gets a couple of hundred MB shunted in to it over the course of things, but has never started swapping. Certainly no unexplained lock ups.

---druck

No problems in the past day, with chrome running nytimes.com, youtube, animated weather imagery and occasional forays on amazon. I still harbor a predjudice that nytimes.com is at least part of the trouble, but repeatable evidence is exceedingly scarce..

I get bob@raspberrypi:~ $ ps -A | grep Xorg 1624 tty1 01:21:14 Xorg bob@raspberrypi:~ $ ps -A | grep wayland bob@raspberrypi:~ $ so I guess it's Xorg.

Thanks for writing!

bob prohaska

This just out, maybe it'll help: The following packages will be upgraded: ghostscript libgs9 libgs9-common linux-libc-dev raspberrypi-bootloader raspberrypi-kernel

Fingers crossed, along with all other appendages 8-)

bob prohaska