My Server Ran Out of Brain
Let me open with the confession, because the confession is the whole story.
I run a full KDE Plasma desktop on a cloud server. Not a lightweight window manager. Not some ascetic tiling thing that real sysadmins use to signal virtue. Full Plasma. With Firefox. And PyCharm. And Rider. All of it resident on a 16GB droplet, humming away in a datacenter, waiting for me to connect over remote desktop and pretend this is a normal way to live.
I did this on purpose. I am tech's bitch, and my rent is due daily.
The Opinion
Here's the thing about a server with a full desktop, a browser, and two JetBrains IDEs on it: JetBrains does not know it's on a server. JetBrains thinks it's on a workstation, because JetBrains is correct and I am the one who's lying.
The droplet had 16GB of RAM and — I want you to sit with this — zero swap configured. None. Not a byte. I had built the machine, hardened it, locked it down, and then skipped the single oldest item on the Linux checklist. Forty years of institutional knowledge says "add swap." I said "nah, it's got 16 gigs, it's fine."
The server eventually expressed an opinion. The opinion was load average 128.
If you've never seen a load average of 128, it is not a number that means "busy." It's a number that means the machine has entered a spiritual state. Every session frozen. Every process in D-state — uninterruptible sleep, the process equivalent of a Marine standing at parade rest in the rain, unable to move, unable to be dismissed, waiting on I/O that is never coming because the kernel is too busy having a nervous breakdown to deliver it.
The Fix, Which My Ancestors Knew
The fix was so old-school it's embarrassing to type. An 8GB swapfile. Written into fstab so it survives reboot. vm.swappiness=20 so the kernel treats it as a fire escape, not a lounge.
That's it. That's the whole fix. Technology that predates my enlistment.
Load fell from 128 to about 2 within minutes. Zero processes killed. No work lost. The IDEs shook it off and went back to indexing, which is all JetBrains products actually do.
I'd like to say I learned something. Reader, wait a few hours.
The Black Screen That Was Actually A Second Desktop Failing To Be Born
Later that same day I connect to the remote desktop and get a black screen. Not a frozen screen. Not an error. Black. Every connect. Meanwhile I could SSH in and see the desktop was provably alive underneath — processes running, IDEs open, everything fine. The machine was fine. I just wasn't allowed to look at it.
Root cause, and I promise this is real: xrdp's default policy keys a session to its creation geometry. The width and height the session was born at. My session had been dynamically resized as I dragged windows around — 2372x963, then 2644x1131, then 2644x1133 — so its birth dimensions could never be matched again. Ever. By anyone.
So every reconnect said "no existing session matches these dimensions" and spawned a brand-new empty one instead.
And here's the punchline: KDE Plasma refuses to start a second instance for the same user — the shell is single-instance per user D-Bus. So the brand-new session had nothing to render. The black screen wasn't a dead desktop. It was a second desktop failing to be born. I was staring into a delivery room where nothing could arrive.
My real desktop — the one with my open work — was two millimeters of resize away, unreachable, because of the dimensions it had at birth. That's not a bug, that's astrology.
Proving The Desktop Existed
I needed proof the real session was still in there, so I did the creepiest thing you can do to a computer: I screenshotted its headless display from the command line. Reached into a screen nobody could see and took its picture.
DISPLAY=:10 import -window root /tmp/proof.png
Out came a 650KB PNG showing 27 live processes, including five JetBrains IDE windows, all rendering happily to a display with no viewer. A full desktop, performing for an empty theater, every frame, to nobody. If that's not a metaphor for blogging I don't know what is.
The Rescue
The rescue path killed nothing that mattered — one empty ghost session got put down — and restarted nothing: a VNC bridge attached directly to the original display, confined to the private mesh so it never touches the public internet. Connected through it and there was my real session — IDEs open, exactly as I'd left them, mildly annoyed at being observed.
The shipped fix is a dedicated "IDE-Desktop" entry in the remote-desktop session menu that bridges straight to the long-lived session. Now reconnecting lands on the actual desktop instead of birthing another ghost. The ghosts have been informed.
The Rule
I wrote this into fleet memory so my AIs can recite it back to me the next time I get clever:
A cloud server running desktop IDEs is a workstation wearing a server costume, and it gets workstation resources — swap included.
In the Corps we had a saying: your gear doesn't care about your intentions, it cares about your maintenance. The droplet never wanted to be a workstation. I dressed it up as one, skipped the maintenance, and it filed two grievances in one week — first through the load average, then through geometry.
Both grievances were sustained. Swap is configured. The session menu has a door that goes to the right room. And somewhere in a datacenter, a desktop is rendering five IDE windows to a screen, whether or not anyone is watching.
I am tech's bitch. But my swapfile is persisted in fstab, and today that feels like a win.
