Diagnose a killed process on a server
By Flavio. Task: By Flavio 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. This is the first post in a series about the things I do with AI to run my business, outside of writing code. This one is about servers. I run a small Ubuntu server on DigitalOcean for Sendy, 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 from 18.04 to 20.04, then 22.04, then 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 on the server, fix it, and verify the fix. 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, with no error and no explanation. 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: Then I described the problem: I gave it no hints, because I had none. Black Friday · opens November 23 A new AI Workshop cohort for $99, reduced from $299 My Black Friday offers open November 23. Join the new AI Workshop cohort for $99 instead of $299, or get all four TypeScript, React, Git, and AHA Stack masterclasses for $49. Join the separate email lists to hear when each offer opens. What Codex did Here’s the session, trimmed a bit: 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: 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. Here are the numbers from the logs side by side: MySQL and Claude Code alone take about 1,650 of the 1,950 available, before Apache and the system get their share. 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 How I fixed my DevOps mistakes with AI. Looking back, adding a 2 GB swap file was the cheaper fix, and it’s what Codex listed first: Then make it permanent by adding a line to /etc/fstab: 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. The commands from this session and the rest of the server series are collected in The Linux commands I actually needed to run a server this year. Want me to talk about your product? You can sponsor this site. Free ebooks Want to go deeper? Subscribe to my newsletter and open my free download library for books, courses, and software.; tools: Codex, Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: The agent requires SSH access and appropriate permissions to read system logs. The diagnosis depends on the availability of kernel logs. The user lacked Linux server skills, relying entirely on the agent for interpretation. Proposed fixes like adding swap or resizing droplets require manual execution or explicit approval..
Tools
Published on Agent Work Atlas:
Overview
By Flavio
Workflow
By Flavio 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. This is the first post in a series about the things I do with AI to run my business, outside of writing code. This one is about servers. I run a small Ubuntu server on DigitalOcean for Sendy, 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 from 18.04 to 20.04, then 22.04, then 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 on the server, fix it, and verify the fix. 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, with no error and no explanation. 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: Then I described the problem: I gave it no hints, because I had none. Black Friday · opens November 23 A new AI Workshop cohort for $99, reduced from $299 My Black Friday offers open November 23. Join the new AI Workshop cohort for $99 instead of $299, or get all four TypeScript, React, Git, and AHA Stack masterclasses for $49. Join the separate email lists to hear when each offer opens. What Codex did Here’s the session, trimmed a bit: 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: 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. Here are the numbers from the logs side by side: MySQL and Claude Code alone take about 1,650 of the 1,950 available, before Apache and the system get their share. 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 How I fixed my DevOps mistakes with AI. Looking back, adding a 2 GB swap file was the cheaper fix, and it’s what Codex listed first: Then make it permanent by adding a line to /etc/fstab: 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. The commands from this session and the rest of the server series are collected in The Linux commands I actually needed to run a server this year. Want me to talk about your product? You can sponsor this site. Free ebooks Want to go deeper? Subscribe to my newsletter and open my free download library for books, courses, and software.
Reported result
The agent successfully identified the root cause (OOM kill) in one pass without modifying the production server. The user noted that the agent's behavior of stating hypotheses, checking evidence, and asking before changing anything was ideal for production environments. No specific performance metrics or cost savings were reported.
Human role
The original post does not say how a person stayed involved.
Limitations
The agent requires SSH access and appropriate permissions to read system logs. The diagnosis depends on the availability of kernel logs. The user lacked Linux server skills, relying entirely on the agent for interpretation. Proposed fixes like adding swap or resizing droplets require manual execution or explicit approval.
Try it
Act as a DevOps assistant. I have a remote Ubuntu server [replaceable: IP/Hostname] where a process [replaceable: process name] is crashing silently. Connect via SSH using [replaceable: SSH command/key path]. Do not modify anything yet. First, check system resources (free -h) and kernel logs (journalctl -k or dmesg) for OOM killer events or errors related to the process. Report your findings: 1. Hypothesis for the crash. 2. Evidence from logs. 3. Recommended fixes ordered by risk (e.g., add swap, resize instance). Wait for my confirmation before executing any changes. If logs are unclear, ask for specific log excerpts.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.