How to Keep OpenClaw Running After SSH Disconnect (PM2 + systemd Guide)

If you’re running OpenClaw on a remote server, perhaps a DigitalOcean Droplet or a self-hosted Ubuntu machine, and you’ve noticed that your OpenClaw processes stop as soon as your SSH session disconnects, you’re not alone. This isn’t an OpenClaw specific issue, but a fundamental aspect of how processes are managed in a typical Linux environment. When you log out of SSH, the shell sends a SIGHUP (Hangup) signal to all processes that are children of the shell. Unless these processes are specifically configured to ignore this signal, they will terminate. This guide will walk you through a robust solution using PM2 for process management and systemd for ensuring PM2 itself starts automatically on boot.

Affiliate Disclosure: As an Amazon Associate, we earn from qualifying purchases. This means we may earn a small commission when you click our links and make a purchase on Amazon. This comes at no extra cost to you and helps support our site.

Understanding the Problem: SIGHUP and Shell Sessions

When you execute openclaw start from your SSH terminal, OpenClaw runs as a child process of your shell session. The shell, usually Bash or Zsh, acts as the parent. If you close your terminal window, lose your internet connection, or explicitly type exit, the shell process terminates. As a courtesy (or often, a necessity), the shell then sends a SIGHUP signal to its child processes. Many programs, including OpenClaw by default, are configured to interpret SIGHUP as a command to shut down. This is why your OpenClaw instance goes offline when you disconnect. While tools like nohup or screen/tmux can help, they are often stop-gap measures. nohup can be finicky with complex applications, and screen/tmux require manual re-attachment, which isn’t ideal for long-running services.

Introducing PM2: A Production Process Manager for Node.js Applications

PM2 is a production process manager for Node.js applications with a built-in load balancer. While OpenClaw isn’t strictly a Node.js application (it’s Python), PM2 is incredibly versatile and can manage any arbitrary command. It handles daemonization, logging, automatic restarts, and clustering, making it perfect for keeping OpenClaw alive. Its key feature for our use case is its ability to detach processes from the current shell, making them immune to SIGHUP signals.

First, ensure you have Node.js and npm installed on your server. If not, the easiest way on Ubuntu/Debian is:

sudo apt update
sudo apt install -y nodejs npm

Then, install PM2 globally:

sudo npm install pm2 -g

Now, instead of running OpenClaw directly, we’ll use PM2 to manage it. Navigate to your OpenClaw installation directory (e.g., /opt/openclaw or wherever you cloned it). Replace python3 main.py start with your actual OpenClaw start command if it’s different. Make sure you’re in the OpenClaw root directory.

cd /path/to/your/openclaw/directory
pm2 start "python3 main.py start" --name "openclaw"

The --name "openclaw" flag gives your OpenClaw process a friendly name in PM2, making it easier to manage. After running this, you can immediately disconnect your SSH session. When you reconnect and run pm2 list, you should see your OpenClaw process listed as “online”.

Persisting Processes Across Reboots with PM2 and systemd

While PM2 keeps OpenClaw running after an SSH disconnect, it doesn’t automatically restart your processes if the server itself reboots. For that, we need to integrate PM2 with systemd, the init system used by most modern Linux distributions. PM2 has a built-in command to generate a systemd unit file.

pm2 startup systemd

This command will output instructions that are specific to your system and user. It usually looks something like this:

[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/local/lib/node_modules/pm2/bin/pm2 startup systemd -u your_username --hp /home/your_username

Make sure to copy and execute the command exactly as PM2 outputs it, replacing your_username with your actual username. This command creates a systemd service file (e.g., ~/.config/systemd/user/pm2-your_username.service or similar) that will start PM2 at boot. It also enables and starts this service.

After generating the startup script, you need to save your currently running PM2 processes so they are automatically restored on reboot:

pm2 save

Now, if your server reboots (e.g., due to a software update or power outage), PM2 will start automatically, and then PM2 will restart your OpenClaw process. You can verify the systemd service status with:

systemctl --user status pm2-your_username.service

Remember to replace your_username. The --user flag is crucial here because PM2 typically generates a user-level systemd service, not a system-wide one.

Non-Obvious Insight: Logging and Resource Management

One common pitfall when running OpenClaw with PM2 is neglecting log management. PM2 automatically captures stdout and stderr, but if you have high-volume logging, these log files can grow indefinitely and consume disk space. By default, PM2 logs are stored in ~/.pm2/logs/. It’s a good practice to set up log rotation for these files. While PM2 has a pm2-logrotate module, for simplicity, you can also manage this with a standard system-wide logrotate configuration. Create a file like /etc/logrotate.d/pm2:

/home/your_username/.pm2/logs/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 your_username your_username
    sharedscripts
    postrotate
        pm2 reloadLog 'openclaw' > /dev/null
    endscript
}

Replace your_username with your actual username. This configuration rotates logs daily, keeps 7 compressed old logs, and tells PM2 to reload its log streams after rotation, preventing data loss. Also, keep an eye on OpenClaw’s own resource usage. While PM2 is lightweight, OpenClaw itself, especially with complex model interactions or high concurrency, can be memory-intensive. This setup works best on a VPS with at least 1GB of RAM dedicated to OpenClaw and the OS. On a Raspberry Pi, especially older models, you might run into memory swap issues if your OpenClaw configuration is demanding, leading to instability or slow responses. Always monitor your RAM and CPU usage with htop or free -h.

The exact next step you should take to secure your OpenClaw instance is to run pm2 save in your OpenClaw directory to ensure your current configuration is persisted across server reboots.

Frequently Asked Questions