Linux Process Management with Supervisord: Keep Your Apps “Alive” After Crashes

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

What happens when your app suddenly “drops dead”?

Every developer has likely experienced this: code runs perfectly on local, but after a few hours on a Linux server, it “craps out” for no apparent reason. It could be a logic bug causing a memory leak, or simply the server rebooting after an update.

The 2 AM nightmare of a client calling because the site is down is all too real. In those moments, frantically SSHing into the server to manually restart scripts is just a band-aid. While systemd is powerful, today I’ll introduce a “softer,” more developer-friendly tool: Supervisord. It’s the perfect assistant to help your app get back on its feet every time it stumbles.

What is Supervisord and why do developers love it?

Simply put, Supervisord is a Process Control System written in Python. It acts like a dedicated butler, constantly watching over the programs you entrust to it. If a script dies, Supervisord will instantly restart it in the blink of an eye.

Why not just use systemd and be done with it? In reality, systemd is more focused on low-level root system management. Supervisord wins developers over with several key strengths:

  • Extremely easy configuration: Just a few lines in a .conf file and you’re good to go—no need to learn complex System Unit syntax.
  • No more full disks: It automatically captures logs from stdout/stderr and supports log rotation. You can limit each log file to, say, 50MB.
  • User Empowerment: Developers can manage their own processes without constantly asking sysadmins for sudo/root access.
  • Group Management: You can start or stop a whole cluster of 20-30 workers with a single command.

Real-world experience: Lessons from a 50-script crawler fleet

Back when I was managing a fleet of data crawling scripts for an e-commerce project, I struggled with bloated logs. On an old CentOS 7 server with only a 20GB SSD, failing scripts writing logs uncontrollably would freeze the server overnight.

After switching to Supervisord, everything changed. I configured each script to keep a maximum of 5 old log files, 10MB each. As a result, disk space was never an issue again. Junior developers on the team felt confident modifying configs and running supervisorctl update without fear of breaking the system. The team’s workflow became 3-4 times smoother.

Install Supervisord in just 1 minute

Most Linux distributions currently have Supervisord available in their official repositories.

For Ubuntu/Debian

sudo apt update
sudo apt install supervisor

For CentOS/AlmaLinux/Fedora

sudo yum install epel-release
sudo yum install supervisor

Once installed, enable it to run automatically on server boot:

sudo systemctl start supervisord
sudo systemctl enable supervisord

The magic is in the configuration file

Supervisord scans for configuration files in /etc/supervisor/conf.d/. Avoid putting everything in one place; create a separate file for each app for better management.

For example, if I have a Python script at /var/www/myapp/app.py, the myapp.conf configuration file would look like this:

[program:myapp]
command=/usr/bin/python3 /var/www/myapp/app.py
directory=/var/www/myapp
user=deployuser
autostart=true
autorestart=true
startsecs=10
stderr_logfile=/var/log/myapp/myapp.err.log
stdout_logfile=/var/log/myapp/myapp.out.log
stdout_logfile_maxbytes=20MB
stdout_logfile_backups=5

Quick explanation of “survival” parameters:

  • autorestart: If the app dies (non-zero exit code), Supervisord restarts it immediately.
  • startsecs=10: The app must run stably for at least 10 seconds to be considered successful. This prevents infinite restart loops if the app crashes instantly.
  • stdout_logfile_maxbytes=20MB: Once the log reaches 20MB, it automatically rotates and creates a new one. Total peace of mind!

Professional operation with supervisorctl

This is the CLI tool that lets you control processes without touching system files. After editing a config file, just notify Supervisord with these two commands:

sudo supervisorctl reread
sudo supervisorctl update

To see which apps are “alive” or “dead,” use:

sudo supervisorctl status

Pro tip: You can view real-time logs for an app without hunting for the file using the tail command:

sudo supervisorctl tail -f myapp

Handling high-volume Queues

If you’re using Laravel or Node.js and need to run 10-20 workers processing jobs simultaneously, don’t copy the config into multiple files. Use numprocs instead:

[program:laravel-worker]
command=php /var/www/project/artisan queue:work
process_name=%(program_name)s_%(process_num)02d
numprocs=10
autostart=true
autorestart=true
user=www-data

With this configuration, Supervisord automatically spawns 10 parallel worker processes. If one hangs, the other 9 keep working, ensuring your system never hits a bottleneck.

Conclusion

Using Supervisord doesn’t just make your server more stable; it helps you sleep better at night. It thoroughly solves the problems of premature app deaths and messy log management without requiring deep sysadmin skills.

Give it a try in your next project. If you run into issues configuring complex apps like Docker or Go, leave a comment below and I’ll help out. Happy server managing!

Share: