X11 crash: fix black screen in 5 minutes

Yeah, that sucks. You reboot your Linux machine, or maybe you just left it for lunch, and bam—black screen with a blinking cursor or a frozen login screen. The X11 display server crashed. Don't panic. I've seen this a hundred times. Let's get you back to a desktop in under five minutes.

The two quick fixes that work most of the time

These are the steps I use first, in this order. Don't skip the first one.

Fix 1: Remove the stale lock file

When X11 crashes badly, sometimes it leaves a lock file behind. The next time you try to start X, it sees that lock file and thinks another display is running—so it refuses to start. Classic.

Switch to a TTY. Press Ctrl + Alt + F2 (or F3, F4, doesn't matter). You'll get a text login prompt.
Log in with your username and password.
Remove the lock file by running:
```
sudo rm /tmp/.X0-lock
```
Restart the display manager (this is what gives you the GUI login screen). The command depends on what you use:
- If you use GDM (GNOME): sudo systemctl restart gdm
- If you use SDDM (KDE): sudo systemctl restart sddm
- If you use LightDM: sudo systemctl restart lightdm
Wait 10 seconds. You should see the login screen again. If you don't, switch back to TTY (press Ctrl + Alt + F2) and check for errors with sudo journalctl -xe | grep -i xorg.

What to expect: After removing the lock file and restarting the display manager, you'll either get a working GUI or—if the crash was deeper—you'll still get a black screen. That's when you move to Fix 2.

Fix 2: Reset the Xorg configuration (or delete the bad one)

X11 stores its configuration in /etc/X11/xorg.conf or sometimes in a file inside /etc/X11/xorg.conf.d/. If you installed a new graphics driver or updated the kernel, that config might be corrupt. The easiest fix is to delete it and let Xorg auto-detect your hardware.

Press Ctrl + Alt + F2 to get to a TTY.
Log in.

Back up the old config (just in case):

sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

Restart the display manager again:
```
sudo systemctl restart gdm
```
(replace gdm with sddm or lightdm if you use something else)

What to expect: After you delete the config, Xorg will fall back to its built-in auto-detection. Most modern GPUs are supported out of the box. You'll get a generic but working desktop. Later, you can tweak the config again if you need something special (like multiple monitors).

Why the X11 server crashed in the first place

X11 is old. Like, 1980s old. It works great until something changes—a kernel update, a new driver, a bug in a window manager. The crash usually happens because:

GPU driver crashed. The NVIDIA or AMD driver had a fault, and X11 couldn't recover. This is common after a kernel upgrade because the driver module wasn't rebuilt.
Locked resources. Like the lock file I mentioned, but also things like the /tmp/.X11-unix/ socket directory can get corrupted.
Out of memory. If your system ran out of RAM, the OOM killer might kill the X server. That's rare but happens.
Bug in a compositor. If you use Compton or Picom with weird settings, they can crash X11. I've seen this with Picom's blur settings on older Intel GPUs.

The real fix is to read the Xorg log. After you get back to a desktop, run:

cat /var/log/Xorg.0.log | grep -i error

That will show you the exact error. Most people skip this and then wonder why it crashes again next week. Don't be that person.

Less common variations of this crash

These don't happen as often, but when they do, the standard fixes above won't work. Here's what I've seen in the field:

Crash when switching from Wayland to X11

If you're on a distro that defaults to Wayland (like Fedora or Ubuntu 22.04+), switching to X11 at the login screen can cause a crash. The reason: Wayland left some lingering processes that hold onto the GPU. Fix this by:

At the GDM login screen, click the gear icon and choose Ubuntu on Xorg (or GNOME on Xorg).
If it crashes anyway, switch to TTY and run sudo killall -9 wayland, then restart gdm.

Crash after waking from suspend

This is a classic for laptops with hybrid graphics (Intel + NVIDIA). The GPU doesn't reinitialize after sleep. Fix this by:

Edit the suspend script: sudo nano /etc/systemd/system/suspend-fix.service

Add this content:

[Unit]
Description=Fix X11 after suspend
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/bin/true

[Install]
WantedBy=sleep.target

Save and enable: sudo systemctl enable suspend-fix.service
Then create a script in /usr/lib/systemd/system-sleep/ that reloads the NVIDIA driver. Too long to detail here, but a web search for "nvidia suspend fix X11" gives you the exact script.

Crash from a bad monitor EDID

Rare, but I've had it happen with cheap monitors. X11 tries to read the monitor's EDID data (the model info) and if that's corrupt, it crashes. Fix: force a generic EDID by adding this to /etc/X11/xorg.conf.d/10-monitor.conf:

Section "Monitor"
  Identifier "Monitor0"
  Option "UseEDID" "false"
  Option "Modeline" "1920x1080 60.0  148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync"
EndSection

Then restart the display manager.

How to prevent this from happening again

You can't stop every crash—Linux is not Windows, and things break. But you can make it rare. Here's what I tell my techs:

Don't install GPU drivers manually unless you need them. The open-source drivers (nouveau for NVIDIA, modesetting for Intel/AMD) are stable. The proprietary NVIDIA driver is better for gaming, but it breaks more often. Pick your poison.
Pin your kernel version. If you're on Ubuntu, run sudo apt-mark hold linux-image-$(uname -r) after you find a stable kernel. Then only upgrade when you have time to fix things.
Check the log after every boot. Run journalctl -xb | grep -i xorg and look for yellow or red messages. If you see an error, fix it before it becomes a crash.
Use a TTY for heavy GPU work. If you do machine learning or mining, don't do it through X11. Use tmux in a TTY instead. X11 will get slower and eventually crash under GPU load.

That's it. Fix the lock file, delete the config, or handle the edge cases. Nine times out of ten, one of these gets you back. If not, you're looking at a deeper problem—maybe your GPU is dying, or your disk has bad sectors. But that's another article.