Force quit frozen apps in GNOME. Safely.
The X on a window only asks an app to close. A frozen app never answers.
- Overview: hold Ctrl and every close button turns red. Click one and the app is gone. Release Ctrl and nothing has changed.
- Keyboard: Ctrl+Delete on a window selected in the overview.
- Dash and app grid: right-click a running app, Force Quit.
- "App is not responding": the dialog's Force Quit button is replaced with one that cannot take your session down (why).
 |
 |
| Hold Ctrl in the overview | Right-click a running app |
Windows that normally have no X get one while Ctrl is held: Wine
programs with a dialog open, windows with attached dialogs. Flatpak, Bottles
and other sandboxed apps are killed by their real process, not the one they
report from inside the sandbox.
curl -fsSL https://raw.githubusercontent.com/lucaswotta/control-kill/main/install.sh | bashThen log out and back in (GNOME on Wayland only loads extension code at
login). The extension is already enabled. To remove it, pipe the same script
to bash -s -- --uninstall.
From source: git clone, then make install.
gnome-extensions prefs control-kill@lucaswotta.github.io, or the gear in
Extensions.
| Setting | Default | |
|---|---|---|
| Ask apps to quit first | off | SIGTERM, then SIGKILL three seconds later if the app is still there |
| Show a notification | on | names the app that was force quit |
| Armed colour | red | text and border adapt to stay readable |
| Play a sound | off | bundled sound or any Ogg Vorbis / WAV file |
The sound follows the system's alert sound setting. To use an MP3, convert it:
ffmpeg -i in.mp3 -ac 1 -c:a libvorbis -q:a 4 out.oga.
Warning
A force quit loses unsaved work and takes every window of the app with it.
- The PID GNOME reports for the window, unless it is GNOME Shell's own. For X11 windows that comes from the X server, which gives the host PID even for sandboxed apps.
- Otherwise, the owner of the app's D-Bus name, asked of the bus daemon (which answers even when the app is hung).
- If that process lives in the systemd unit GNOME started for this very app, the whole unit is signalled, helpers included. A process started from a terminal is signalled alone.
- With no PID at all, the app's unit, if exactly one exists.
- Nothing trustworthy: a normal close request. Never a guess.
Each process or unit gets one signal per action, and the shell's own PID and unit are refused at the last step.
meta_window_kill() runs kill(pid, 9) on whatever meta_window_get_pid()
returns (mutter, src/core/delete.c).
For a Wayland client whose socket the compositor created, that is the
compositor itself: Nautilus reports GNOME Shell's PID. Force quitting such a
window from the "not responding" dialog kills GNOME Shell and logs you out.
Control Kill never calls it.
_NET_WM_PID is no better: a Wine program under Bottles reports PID 157 from
inside its sandbox while its real PID is 5776.
GNOME Shell 46 to 51. Tested on 48 by hand and by the test suite; the shell
code it touches was checked against the sources of every listed release. It
patches private methods of WindowPreview, AppMenu and CloseDialog, so a
new GNOME release can break it: if the close buttons misbehave after an
upgrade, disable it first.
Bugs, translations and patches are welcome: see CONTRIBUTING.md. Available in English, Portuguese (Brazil), Russian and Spanish.
GPL-3.0-or-later. The kill sound is UI back sound by KieranKeegan, CC0 1.0, trimmed and converted.