Every few days my Cinnamon session would vanish — every open window gone, back to the login screen, hours of unsaved work with it.
Twenty times, easy. "Cinnamon is buggy," I told myself. It wasn't Cinnamon. It was never Cinnamon.
The symptom
A workstation running Cinnamon on X11. Mid-work, the whole desktop would just evaporate — no dialog, no "sorry, something crashed," just an instant cut to the greeter. Everything unsaved died with it.
The maddening part: the exact same Cinnamon, same version, ran perfectly on every other machine I own. So it felt like a Cinnamon bug specific to this box.
That assumption cost me weeks.
The first rule of debugging: the thing that dies is not always the thing that's broken. Cinnamon was the victim, loudly falling over. The killer was upstream, and silent.
Ruling out the obvious suspects
Before blaming anything, I wanted evidence, not vibes.
Did a process actually crash? A real segfault leaves a core dump. So:
coredumpctl list
Empty. Across every boot. Nothing — not Cinnamon, not muffin, not Xorg — had ever crashed hard enough to dump core. That already kills the "Cinnamon segfaults" theory. Something was shutting the session down cleanly, not crashing it.
Did the whole machine crash? A hard lockup or panic leaves a truncated log and a dirty reboot. So I looked at how the previous boot actually ended:
journalctl --list-boots # find the boot that died
journalctl -b -1 -e # jump to the tail of it
The tail was a clean, orderly systemd-poweroff — filesystems unmounted gracefully, poweroff. target reached. No panic. No crash.
I KNOW! I was shutting it down manually and restarting to hopelessly try to clean whatever memory corruption would trigger a cut-n-no-log crash!
The machine went down politely. Which meant the desktop had already died earlier, and I'd simply rebooted to recover. The real event was buried further up the log.
The smoking gun
If it wasn't a crash and it wasn't hardware, something was deliberately killing my session. On a modern systemd box, there's exactly one well-meaning assassin that fits that description:
journalctl | grep "systemd-oomd killed"
There it was. Not once — fourteen times in the retained journal alone:
systemd-oomd[...]: Killed /user.slice/user-1000.slice/user@.../session.slice/dbus.service
due to memory pressure for .../user@... being 77.55% > 50.00% for > 20s with reclaim activity
systemd[...]: dbus.service: systemd-oomd killed 5 process(es) in this unit.
And immediately after, the desktop's death rattle:
cinnamon-session-binary[...]: CRITICAL: Unable to start session:
Lost name on bus: org.gnome.SessionManager
cinnamon-session-binary[...]: Application 'cinnamon.desktop' killed by signal 15
Read that chain top to bottom and the whole mystery collapses:
1. systemd-oomd decided my user session was under memory pressure.
2. It reached into my session cgroup and SIGKILLed dbus.service — the session bus.
3. Cinnamon lives on that bus. With the bus gone, it instantly lost org.gnome.SessionManager.
4. The session manager can't survive losing its own name, so it tore the whole session down — every app with it.
5. I landed back at the login screen, cursing Cinnamon for a murder it didn't commit.
On other occasions oomd went even bigger and killed init.scope — the entire user manager — in one shot. Same result, faster.
Why does this fire on a machine with plenty of RAM?
This is the counterintuitive core of the whole thing, and it's why it ambushes people.
systemd-oomd does not act on free memory. It acts on memory pressure — PSI (Pressure Stall Information). PSI measures the percentage of time tasks are stalled waiting on memory, not how many bytes are free. You can have gigabytes free and still register high pressure if a cgroup is thrashing reclaim in bursts — swapping, dropping and refaulting page cache, that sort of churn.
Check what oomd is watching and the thresholds it's using:
oomctl
Mine reported the trap plainly:
Default Memory Pressure Duration: 20s
Memory Pressure Monitored CGroups:
Path: /user.slice/user-1000.slice/user@....service
Memory Pressure Limit: 50.00%
Memory Pressure Duration: 20s
So the policy was: if my user session spends more than 50% of its time stalled on memory for 20 seconds, start killing processes inside it. On a busy workstation running VMs, compilers, and browsers, a 20-second pressure spike above 50% is normal Tuesday behavior — not an emergency.
But oomd treated it as one, and its idea of "relieving pressure" was to shoot whatever cgroup looked heaviest in my session. That kept landing on the session bus or the user manager: the two processes guaranteed to take the whole desktop down.
Where was that 50% policy coming from? Straight from the vendor default applied to the user manager unit:
systemctl show "user@$(id -u).service" \
-p ManagedOOMMemoryPressure -p ManagedOOMMemoryPressureLimit
# ManagedOOMMemoryPressure=kill
# ManagedOOMMemoryPressureLimit=2147483648 # <- that's 50% of UINT32_MAX
kill, at 50%, on the cgroup that contains my entire graphical session. That's the loaded gun.
The gotcha that wastes an afternoon
You might think "fine, I'll just disable it":
systemctl is-enabled systemd-oomd # disabled
systemctl is-active systemd-oomd # active (!!)
Disabled but active. systemd-oomd is socket/D-Bus-activated, so "disabling" the service does nothing — it springs right back to life on demand and keeps killing you. You have to either exempt your session from it or mask it outright. A plain disable is a no-op here.
The fix
Two roads.
OptionA - systemctl disable --now systemd-oomd
Felt good... felt justified after all the work loss and frustration.
BUUUUUT I took the higher ground and the surgical one.
Option B — keep oomd, but forbid it from touching my desktop (recommended)
systemd-oomd is genuinely useful as a last line of defence against a runaway process eating the whole machine. I didn't want to throw that away — I just wanted it to stop treating a busy interactive session as an OOM emergency.
Two drop-ins do it. First, tell systemd that oomd may not pressure-kill the user session:
sudo mkdir -p /etc/systemd/system/user@.service.d
sudo tee /etc/systemd/system/user@.service.d/99-no-oomd.conf >/dev/null <<'EOF'
[Service]
ManagedOOMMemoryPressure=auto
ManagedOOMSwap=auto
EOF
auto means "don't actively manage this — only act if an ancestor explicitly opts in," which nothing does. That removes my session from oomd's watch list entirely.
Second, make oomd far less twitchy globally, so a brief pressure spike anywhere never trips it. Twenty seconds becomes a full hour:
sudo mkdir -p /etc/systemd/oomd.conf.d
sudo tee /etc/systemd/oomd.conf.d/50-relax.conf >/dev/null <<'EOF'
[OOM]
DefaultMemoryPressureDurationSec=1h
EOF
Apply it live — no reboot, no logout, running programs untouched:
sudo systemctl daemon-reload
sudo systemctl restart systemd-oomd
Both files live under /etc, so they override the vendor defaults in /usr/lib and survive updates and reboots.
Verify it actually took
Don't trust, confirm:
oomctl
Default Memory Pressure Duration: 1h
Memory Pressure Monitored CGroups: <-- empty
Swap Monitored CGroups: <-- empty
An empty monitored-cgroups list is the win. oomd is still running, still available to catch a genuine machine-wide meltdown — but my desktop session is no longer on its list of things it's allowed to shoot. It cannot kill Cinnamon anymore, because it isn't watching it at all.
Why not Option A — evict oomd entirely (the blunt and the still desired by revenge... but)
If you don't care for oomd's protection and just want it gone for good, mask it so socket-activation can't resurrect it:
sudo systemctl disable --now systemd-oomd
sudo systemctl mask systemd-oomd
On a machine with generous RAM and swap, the kernel's own OOM killer is a perfectly adequate backstop, and this is a defensible choice. I preferred keeping a tamed oomd over removing it.
Takeaways
- The process that dies is rarely the process that's broken. Cinnamon was the last domino, not the first. Follow the chain upstream from the visible failure.
- No core dump means it wasn't a crash — it was a kill. coredumpctl list is a thirty-second test that redirects the entire investigation.
- systemd-oomd judges pressure, not free memory. "But I have 32 GB free" is not a defence; PSI can spike under reclaim churn while plenty of RAM sits free. oomctl shows you exactly what it's watching and at what thresholds.
- The default 50% / 20s policy on the user session is hostile to interactive workloads. A busy desktop routinely breaches it without anything actually being wrong.
- disable is a trap for socket-activated units. Check is-active, not just is-enabled. If you truly want it gone, mask it.
Twenty "Cinnamon crashes," zero of them Cinnamon's fault. Sometimes the ghost in the machine is just an overzealous babysitter with a SIGKILL and a bad definition of "emergency."
Happy days.. Cinnamon is rock solid. I-m happy again. Lets push the machine to the limit as we usually do...after all I DID PAY FOR 100% of that thing.
