# Debugging a process killed on my server with Codex

> Claude Code kept dying a few seconds after starting on my Ubuntu server. I pointed Codex CLI at the server over SSH and it found the Linux OOM killer in the kernel logs. Here is the whole session.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-09-15 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/server-process-killed/

This is the first post in a series about the things I do with AI to run my business, not just to write code. Servers, in this case.

I run a small Ubuntu server on DigitalOcean for [Sendy](https://sendy.co/), the self-hosted newsletter app I use to send my emails.

In April 2026 that server was still on Ubuntu 18.04 LTS. A very old version. LTS releases come out every two years and get five years of standard security updates, so 18.04 had been out of support for a while.

I installed Claude Code on the server and used it to do the upgrade. It went 18.04 → 20.04 → 22.04 → 24.04, one step at a time, because Ubuntu doesn't support jumping straight to the latest release.

That worked great. Whenever something broke along the way, the agent could see the error, fix it, and verify the fix. All on the server itself.

Two weeks later Ubuntu 26.04 LTS came out. So I said "let's upgrade again, and I'm safe for two more years."

> Plot twist: there was no upgrade path from 24.04 to 26.04 yet. Ubuntu opens it a few months after the release, with the first point release. So everything you'll read here was useless work. The debugging approach is still worth sharing.

## The problem

I SSH'd into the server and ran `claude`. It was killed after a few seconds. Every time.

No error, no explanation. Just gone.

I had no idea why. So instead of debugging on the server, I ran an agent on my Mac and told it to connect to the server and figure it out. I used Codex CLI.

## Giving the agent access

First I told Codex how to reach the machine:

```text
I want to connect to a server to fix things, use this command to connect:

ssh root@<IP> -i ~/.ssh/digitalocean
```

Then I described the problem:

```text
any time I start claude command on the server, it's killed in a few seconds, why?
```

That's it. No hints, because I had none.

## What Codex did

Here's the session, trimmed a bit:

```text
• I'll reconnect and diagnose the claude process failure directly: confirm which binary runs,
  reproduce once, then check kernel/OOM logs and resource limits. If it is being killed by the
  kernel, the evidence should be in dmesg or journalctl.

✔ You approved codex to run ssh root@<IP> -i ~/.ssh/digitalocean this time

• Ran ssh root@<IP> -i ~/.ssh/digitalocean
  └ Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-107-generic x86_64)
    root@Sendy:~#

• The droplet has about 2 GB RAM and no swap, with MySQL already using close to 1 GB. I'm checking
  claude itself and recent kernel logs before reproducing, so we can separate a CLI issue from an
  OOM kill.

↳ Interacted with background terminal
  └ which claude
    type claude
    free -h
    ps -eo pid,ppid,comm,rss,%mem,%cpu,args --sort=-rss | head -n 15
    ulimit -a
    journalctl -k --since "2 hours ago" --no-pager | grep -Ei "killed process|out of memory|oom|
    claude|node" | tail -n 80

• The kernel logs already show the cause: claude is being killed by the Linux OOM killer. It
  reaches about 860 MB resident memory on a 2 GB droplet with no swap while MySQL is using roughly
  786 MB, so the system has no safety buffer.
```

Notice the first thing it did. Before touching anything, it stated a hypothesis (kernel killing the process) and where the evidence would be (`dmesg`, `journalctl`). Then it went and checked.

The `journalctl -k` command reads the kernel log. The `grep` filters it for the words that show up when Linux kills a process for using too much memory.

And here's the conclusion:

```text
• claude is being killed by the Linux OOM killer.

  Evidence from the server logs:

  Out of memory: Killed process ... (claude)
  anon-rss: ~864MB

  The droplet has only 1.9GiB RAM and 0B swap. MySQL alone is using about 786MB, Apache has
  multiple workers, and claude grows to roughly 860MB resident memory. With no swap, the kernel
  kills claude as soon as memory pressure gets too high.

  Best fixes:

  1. Add swap, probably 2G or 4G, as a quick stabilization fix.
  2. Resize the droplet to more RAM if you want claude to run reliably alongside MySQL/Apache.
  3. Optionally tune MySQL memory lower, but that is secondary.

  I didn't change anything yet.
```

## What the OOM killer is

The **OOM killer** (out of memory killer) is part of the Linux kernel. When the system runs out of RAM and has no swap to fall back on, the kernel picks a process and kills it to keep the machine alive.

It tends to pick the process that grew fastest or uses the most memory. On my server that was `claude`, which needs around 860 MB to run.

**Swap** is disk space the kernel uses as overflow memory. It's slow, but it gives the system a buffer instead of a hard wall. My droplet had none.

## The fix

The problem was memory. Two weeks earlier, the same agent ran fine on the same server. MySQL had grown since then, or Claude Code had. Either way, 2 GB with no swap was not enough anymore.

I decided to resize the droplet and add more RAM. That turned out to be a mistake of its own, and it's the story of the next post.

Looking back, adding a 2 GB swap file was the cheaper fix, and it's what Codex listed first:

```bash
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
```

Then make it permanent by adding a line to `/etc/fstab`:

```text
/swapfile none swap sw 0 0
```

I didn't do that at the time. Both my servers got a swap file later in this series, added by the agent itself.

## What I like about this

I have close to zero Linux server skills. I would have stared at that dying process for an hour.

The agent found the cause in one pass, showed the evidence, listed the fixes in order of risk, and didn't change anything without asking. That's exactly the behavior I want from an assistant working on a production machine.