Skip to content
agentusehub
Sign in+ Submit
Software & DevOpsAny

Diagnose a killed process on a server

Codex CLI over SSH found the OOM killer in kernel logs on a 2 GB droplet with no swap and listed fixes by risk without changing anything.

Read the experience
Time saved
Not reported
Setup time
Not reported
Running cost
Not reported
Cost range
Not reported

Use case overview

Codex CLI over SSH found the OOM killer in kernel logs on a 2 GB droplet with no swap and listed fixes by risk without changing anything.

Read the original report ↗

Reported experience

  1. What they did

    Claude Code kept dying within seconds on the author's Ubuntu droplet. He ran Codex CLI on his Mac and gave it the SSH command for the server, plus the symptom and no hints. Codex asked approval to connect, then checked memory, processes and limits. It grepped the kernel log via journalctl for kill and OOM messages.

  2. How it went

    Codex found the OOM killer ending claude at about 860 MB on a 1.9 GB droplet with no swap, with MySQL using about 786 MB. It ranked fixes and changed nothing.

  3. Worth knowing

    The author resized the droplet, which caused its own problems. He says in hindsight that the first fix Codex listed, a 2 GB swap file, was cheaper.

Example prompts

Try with Claude Code
My server at [user@host] has a process that keeps getting killed, namely [service name]. Connect over SSH and investigate read-only: check kernel logs, memory, swap, and service logs to find the cause. Finish with a diagnosis and a list of possible fixes ranked by risk. Do not change any settings, install anything, or restart services without showing me the exact command and getting my approval first.

Related use cases

Software & DevOps

Port a Chrome extension to Safari

The author had ChatGPT take the Session Buddy extension source from Chrome, port it to Safari and install it, taking about 20 minutes.

ChatGPT