Supervisor Configuration for Process Management: Complete Application Monitoring Guide

Supervisor is a client/server system that allows users to monitor and control processes on UNIX-like operating systems. Unlike traditional init systems, Supervisor is designed specifically for process management, offering automatic restarts, centralized logging, and a simple configuration format. This comprehensive guide covers Supervisor installation, configuration, and best practices for managing production applications reliably.

Introduction

Modern applications often consist of multiple processes that must run continuously: web servers, worker queues, scheduled tasks, monitoring agents, and custom daemons. Managing these processes manually becomes error-prone and time-consuming. Supervisor solves this problem by providing robust process management with minimal complexity.

Why Use Supervisor?

Automatic Restart: Processes that crash are automatically restarted, ensuring high availability without manual intervention.

Centralized Management: Control multiple processes from a single configuration file and command-line interface, simplifying operations.

Process Monitoring: Track process status, resource usage, and uptime through a simple web interface or command-line tools.

Consistent Logging: Capture stdout and stderr from all managed processes in a standardized location, making debugging easier.

User Privileges: Run processes as specific users with controlled permissions, enhancing security.

Simple Configuration: INI-style configuration files are easy to read, write, and maintain compared to complex init scripts.

Process Groups: Organize related processes into groups for bulk operations (start all workers, restart all web servers, etc.).

Supervisor vs. Systemd

While modern Linux distributions include systemd for service management, Supervisor offers distinct advantages:

Application-focused: Designed specifically for application processes, not system services
Cross-platform: Works consistently across different Linux distributions
Simpler configuration: INI format is more intuitive than systemd unit files
Better suited for non-root applications: Easier to manage applications as regular users
Web interface: Built-in web dashboard for monitoring
Development-friendly: Easy to use in development environments

Supervisor excels at managing application-level processes, while systemd is better for system-level services. Many deployments use both: systemd manages Supervisor itself, while Supervisor manages application processes.

Common Use Cases

Web Application Workers: Manage Celery, RQ, or custom worker processes
Application Servers: Run Gunicorn, uWSGI, or Node.js applications
Queue Processors: Monitor and restart message queue consumers
Scheduled Tasks: Manage long-running cron-like processes
Microservices: Coordinate multiple service processes
Development Environments: Manage local development processes
Legacy Applications: Wrap applications without native service support

Prerequisites

Before installing Supervisor, ensure your system meets the requirements.

System Requirements

Minimum Requirements:

Linux server (Ubuntu 20.04+, Debian 11+, CentOS 8+, Rocky Linux 8+)
Python 2.7 or Python 3.4+ (usually pre-installed)
256MB RAM
100MB disk space
Root or sudo access (for system-wide installation)

Recommended for Production:

512MB+ RAM
1GB+ disk space (for logs)
Dedicated monitoring and alerting
Backup strategy for configuration files

Software Prerequisites

Python (2.7 or 3.4+)
pip (Python package manager)
Text editor (vim, nano, etc.)
Basic understanding of process management

Application Requirements

Before using Supervisor to manage your application:

Application should run in foreground (not daemonize itself)
Clear understanding of command-line arguments
Known user/group for process execution
Identified working directory
Environment variables documented

Installation

Supervisor can be installed via package managers or Python's pip.

Method 1: Package Manager Installation (Recommended)

Ubuntu/Debian Installation

# Update package index
sudo apt update

# Install Supervisor
sudo apt install -y supervisor

# Verify installation
supervisord --version

CentOS/Rocky Linux Installation

# Enable EPEL repository
sudo dnf install -y epel-release

# Install Supervisor
sudo dnf install -y supervisor

# Verify installation
supervisord --version

Enable and Start Service

# Enable Supervisor to start on boot
sudo systemctl enable supervisord

# Start Supervisor
sudo systemctl start supervisord

# Check status
sudo systemctl status supervisord

Method 2: Python pip Installation

For latest version or custom installations:

# Install via pip (system-wide)
sudo pip3 install supervisor

# Or install in virtual environment
python3 -m venv /opt/supervisor-env
source /opt/supervisor-env/bin/activate
pip install supervisor

# Verify installation
supervisord --version

Create Configuration Directory

# Create directories
sudo mkdir -p /etc/supervisor/conf.d
sudo mkdir -p /var/log/supervisor

# Generate default configuration
echo_supervisord_conf | sudo tee /etc/supervisor/supervisord.conf

# Configure to include additional configs
sudo tee -a /etc/supervisor/supervisord.conf << 'EOF'

[include]
files = /etc/supervisor/conf.d/*.conf
EOF

Create Systemd Service (for pip installation)

Create /etc/systemd/system/supervisord.service:

[Unit]
Description=Supervisor process control system
Documentation=http://supervisord.org
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/supervisord -c /etc/supervisor/supervisord.conf
ExecReload=/usr/local/bin/supervisorctl reload
ExecStop=/usr/local/bin/supervisorctl shutdown
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable supervisord
sudo systemctl start supervisord

Method 3: Docker Container Management

Use Supervisor inside Docker containers:

Dockerfile Example:

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    supervisor \
    python3 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY app.py /app/app.py

WORKDIR /app

CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf"]

Post-Installation Verification

# Check Supervisor status
sudo supervisorctl status

# Check version
supervisord --version

# Verify configuration
sudo supervisord -c /etc/supervisor/supervisord.conf -t

# Check running processes
ps aux | grep supervisord

Configuration

Supervisor uses INI-style configuration files. Understanding the configuration structure is essential for effective process management.

Main Configuration File

Location: /etc/supervisor/supervisord.conf (package installation) or custom location

Key Sections:

[unix_http_server] - UNIX Socket Interface

[unix_http_server]
file=/var/run/supervisor.sock   ; UNIX socket file path
chmod=0700                       ; Socket file permissions
chown=nobody:nogroup            ; Socket file owner

[inet_http_server] - Web Interface

[inet_http_server]
port=127.0.0.1:9001             ; IP and port for web interface
username=admin                   ; Username for authentication
password=secure_password_here   ; Password for authentication

Security Note: Only bind to localhost (127.0.0.1) unless using firewall rules. Never expose without authentication.

[supervisord] - Main Process Configuration

[supervisord]
logfile=/var/log/supervisor/supervisord.log  ; Main log file
logfile_maxbytes=50MB                        ; Max log file size
logfile_backups=10                           ; Number of log backups
loglevel=info                                ; Log level (critical, error, warn, info, debug, trace)
pidfile=/var/run/supervisord.pid             ; PID file location
nodaemon=false                               ; Run in foreground (false for daemon mode)
minfds=1024                                  ; Minimum file descriptors
minprocs=200                                 ; Minimum process descriptors
user=root                                    ; User to run supervisord as

[supervisorctl] - Control Interface Configuration

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock    ; Use UNIX socket
; serverurl=http://127.0.0.1:9001           ; Or use TCP socket
username=admin                                ; Username for auth
password=secure_password_here                ; Password for auth

[include] - Include Additional Configuration Files

[include]
files = /etc/supervisor/conf.d/*.conf

Program Configuration

Create individual configuration files for each application in /etc/supervisor/conf.d/.

Basic Program Configuration

Create /etc/supervisor/conf.d/myapp.conf:

[program:myapp]
command=/usr/bin/python3 /opt/myapp/app.py           ; Command to run
directory=/opt/myapp                                  ; Working directory
user=myappuser                                        ; Run as this user
autostart=true                                        ; Start on supervisor boot
autorestart=true                                      ; Restart if process exits
startretries=3                                        ; Number of restart attempts
redirect_stderr=true                                  ; Redirect stderr to stdout
stdout_logfile=/var/log/supervisor/myapp.log         ; Log file location
stdout_logfile_maxbytes=10MB                         ; Max log file size
stdout_logfile_backups=5                             ; Number of log backups
environment=PATH="/usr/local/bin",PYTHONPATH="/opt/myapp"  ; Environment variables

Advanced Program Configuration

[program:worker]
command=/opt/venv/bin/celery -A myproject worker --loglevel=info
directory=/opt/myproject
user=worker
numprocs=4                                            ; Run 4 instances
process_name=%(program_name)s_%(process_num)02d     ; Unique names for each instance
autostart=true
autorestart=true
startsecs=10                                          ; Process must stay running for 10s
startretries=3
stopwaitsecs=600                                      ; Wait 600s for graceful shutdown
stopasgroup=true                                      ; Stop process group
killasgroup=true                                      ; Kill entire process group
priority=999                                          ; Start priority (lower starts first)
redirect_stderr=true
stdout_logfile=/var/log/supervisor/worker-%(process_num)02d.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5
stderr_logfile=/var/log/supervisor/worker-%(process_num)02d-error.log
environment=
    DJANGO_SETTINGS_MODULE="myproject.settings",
    DATABASE_URL="postgresql://user:pass@localhost/db",
    REDIS_URL="redis://localhost:6379/0"

Group Configuration

Organize related processes into groups:

[group:webservers]
programs=gunicorn1,gunicorn2,nginx_frontend
priority=999

[program:gunicorn1]
command=/opt/venv/bin/gunicorn myapp.wsgi:application -b 127.0.0.1:8001
directory=/opt/myapp
user=www-data
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/gunicorn1.log

[program:gunicorn2]
command=/opt/venv/bin/gunicorn myapp.wsgi:application -b 127.0.0.1:8002
directory=/opt/myapp
user=www-data
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/gunicorn2.log

Event Listener Configuration

Monitor process events and trigger actions:

[eventlistener:memmon]
command=/opt/venv/bin/memmon -a 200MB -m [email protected]
events=TICK_60

Apply Configuration Changes

After creating or modifying configurations:

# Reload configuration
sudo supervisorctl reread

# Update with new configuration
sudo supervisorctl update

# Or restart supervisord entirely
sudo systemctl restart supervisord

# Verify programs are loaded
sudo supervisorctl status

Practical Examples

Example 1: Managing Django Application with Gunicorn

Application Structure:

/opt/mydjango/
├── manage.py
├── mydjango/
│   ├── __init__.py
│   ├── settings.py
│   └── wsgi.py
└── venv/

Supervisor Configuration (/etc/supervisor/conf.d/django.conf):

[program:django_gunicorn]
command=/opt/mydjango/venv/bin/gunicorn \
    --workers 4 \
    --bind 127.0.0.1:8000 \
    --timeout 60 \
    --access-logfile /var/log/django/access.log \
    --error-logfile /var/log/django/error.log \
    mydjango.wsgi:application

directory=/opt/mydjango
user=www-data
group=www-data
autostart=true
autorestart=true
startsecs=10
stopwaitsecs=30
stopasgroup=true
killasgroup=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/django_gunicorn.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5

environment=
    DJANGO_SETTINGS_MODULE="mydjango.settings",
    SECRET_KEY="your-secret-key",
    DATABASE_URL="postgresql://user:pass@localhost/mydb"

Apply Configuration:

# Create log directory
sudo mkdir -p /var/log/django
sudo chown www-data:www-data /var/log/django

# Update Supervisor
sudo supervisorctl reread
sudo supervisorctl update

# Start application
sudo supervisorctl start django_gunicorn

# Check status
sudo supervisorctl status django_gunicorn

Example 2: Managing Celery Workers

Configuration (/etc/supervisor/conf.d/celery.conf):

; Celery Worker
[program:celery_worker]
command=/opt/myapp/venv/bin/celery -A myapp worker --loglevel=info --concurrency=4
directory=/opt/myapp
user=celery
numprocs=1
autostart=true
autorestart=true
startsecs=10
stopwaitsecs=600
stopasgroup=true
killasgroup=true
priority=998
redirect_stderr=true
stdout_logfile=/var/log/supervisor/celery_worker.log
stdout_logfile_maxbytes=50MB
stdout_logfile_backups=10
environment=DJANGO_SETTINGS_MODULE="myapp.settings"

; Celery Beat (Scheduler)
[program:celery_beat]
command=/opt/myapp/venv/bin/celery -A myapp beat --loglevel=info
directory=/opt/myapp
user=celery
numprocs=1
autostart=true
autorestart=true
startsecs=10
stopwaitsecs=60
priority=999
redirect_stderr=true
stdout_logfile=/var/log/supervisor/celery_beat.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5
environment=DJANGO_SETTINGS_MODULE="myapp.settings"

; Group for easy management
[group:celery]
programs=celery_worker,celery_beat
priority=999

Management Commands:

# Start all Celery processes
sudo supervisorctl start celery:*

# Stop all Celery processes
sudo supervisorctl stop celery:*

# Restart all Celery processes
sudo supervisorctl restart celery:*

# Check status
sudo supervisorctl status celery:*

Example 3: Managing Node.js Application

Configuration (/etc/supervisor/conf.d/nodejs.conf):

[program:nodejs_app]
command=/usr/bin/node /opt/nodeapp/server.js
directory=/opt/nodeapp
user=nodejs
autostart=true
autorestart=true
startsecs=5
startretries=3
stopwaitsecs=10
redirect_stderr=true
stdout_logfile=/var/log/supervisor/nodejs_app.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5
environment=
    NODE_ENV="production",
    PORT="3000",
    DATABASE_URL="mongodb://localhost:27017/mydb"

Example 4: Managing Multiple Instances

Configuration (/etc/supervisor/conf.d/api_servers.conf):

[program:api_server]
command=/opt/api/venv/bin/gunicorn api.wsgi:application --bind 127.0.0.1:%(process_num)s
directory=/opt/api
user=api
numprocs=4
process_name=%(program_name)s_%(process_num)s
autostart=true
autorestart=true
startsecs=10
stopwaitsecs=30
redirect_stderr=true
stdout_logfile=/var/log/supervisor/api_server_%(process_num)s.log
environment=PORT="800%(process_num)s"

This creates 4 instances:

api_server_8000 (listening on port 8000)
api_server_8001 (listening on port 8001)
api_server_8002 (listening on port 8002)
api_server_8003 (listening on port 8003)

Example 5: Custom Application Script

Application Script (/opt/scripts/data_processor.py):

#!/usr/bin/env python3
import time
import sys
import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s',
    stream=sys.stdout
)

logger = logging.getLogger(__name__)

def main():
    logger.info("Data processor started")

    while True:
        try:
            # Simulate data processing
            logger.info("Processing data batch...")
            time.sleep(10)

        except KeyboardInterrupt:
            logger.info("Received shutdown signal")
            break
        except Exception as e:
            logger.error(f"Error processing data: {e}")
            time.sleep(5)

    logger.info("Data processor stopped")

if __name__ == "__main__":
    main()

Supervisor Configuration:

[program:data_processor]
command=/usr/bin/python3 /opt/scripts/data_processor.py
directory=/opt/scripts
user=processor
autostart=true
autorestart=true
startsecs=5
redirect_stderr=true
stdout_logfile=/var/log/supervisor/data_processor.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5

Verification

Check Process Status

# View all process status
sudo supervisorctl status

# View specific program status
sudo supervisorctl status myapp

# View group status
sudo supervisorctl status mygroup:*

# View detailed process information
sudo supervisorctl pid myapp
sudo supervisorctl tail myapp

Monitor Logs

# Tail logs in real-time
sudo supervisorctl tail -f myapp

# Tail stderr
sudo supervisorctl tail -f myapp stderr

# View last 1000 bytes
sudo supervisorctl tail myapp

# Clear log
sudo supervisorctl clear myapp

Process Control

# Start process
sudo supervisorctl start myapp

# Stop process
sudo supervisorctl stop myapp

# Restart process
sudo supervisorctl restart myapp

# Start all processes
sudo supervisorctl start all

# Stop all processes
sudo supervisorctl stop all

# Restart all processes
sudo supervisorctl restart all

Configuration Validation

# Test configuration syntax
sudo supervisord -c /etc/supervisor/supervisord.conf -t

# Reload configuration
sudo supervisorctl reread

# Update processes with new configuration
sudo supervisorctl update

# Show process info
sudo supervisorctl avail

Web Interface Access

If web interface is enabled:

# Access via browser
http://localhost:9001

# Or via SSH tunnel
ssh -L 9001:localhost:9001 user@server
# Then access http://localhost:9001 on local machine

Performance Monitoring

# Check supervisor process resource usage
ps aux | grep supervisord

# Monitor managed processes
watch -n 1 'sudo supervisorctl status'

# Check memory usage of managed processes
for pid in $(sudo supervisorctl pid all); do
    ps -p $pid -o pid,vsz,rss,cmd
done

Troubleshooting

Issue 1: Process Won't Start

Symptom: Process stays in STARTING state or immediately goes to FATAL

Solution:

# Check process logs
sudo supervisorctl tail myapp stderr

# Check supervisord main log
sudo tail -f /var/log/supervisor/supervisord.log

# Common issues:

# 1. Command not found or incorrect path
# Verify command exists
which python3
# Use full path in configuration

# 2. Permission issues
# Check file ownership
ls -la /opt/myapp/
# Correct permissions
sudo chown -R myappuser:myappuser /opt/myapp/

# 3. Working directory doesn't exist
# Create directory
sudo mkdir -p /opt/myapp
sudo chown myappuser:myappuser /opt/myapp

# 4. User doesn't exist
# Create user
sudo useradd -r -s /bin/false myappuser

# 5. Environment issues
# Test command manually as specified user
sudo -u myappuser /usr/bin/python3 /opt/myapp/app.py

# 6. startsecs too short
# Increase startsecs in configuration
# startsecs=10

Issue 2: Process Keeps Restarting

Symptom: Process continuously crashes and restarts

Solution:

# Check application logs
sudo supervisorctl tail myapp stderr

# Check for common issues:

# 1. Application exits immediately
# Ensure application runs in foreground (doesn't daemonize)

# 2. Port already in use
sudo ss -tlnp | grep :8000

# 3. Missing dependencies
# Check if all required packages installed

# 4. Configuration errors in application
# Test application independently

# 5. Resource exhaustion
# Check memory/disk space
free -h
df -h

# Temporarily disable autorestart to investigate
# Edit config: autorestart=false
sudo supervisorctl update
sudo supervisorctl start myapp
# Investigate why it exits

Issue 3: Cannot Connect to Supervisor

Symptom: unix:///var/run/supervisor.sock no such file or connection refused

Solution:

# Check if supervisord is running
sudo systemctl status supervisord

# If not running, start it
sudo systemctl start supervisord

# Check socket file exists
ls -la /var/run/supervisor.sock

# Check permissions
# Socket should be readable/writable by supervisor user

# If using TCP interface, check port
sudo ss -tlnp | grep 9001

# Check configuration
sudo supervisord -c /etc/supervisor/supervisord.conf -t

# Restart supervisord
sudo systemctl restart supervisord

Issue 4: Process Won't Stop

Symptom: Process stays in STOPPING state

Solution:

# Check process status
sudo supervisorctl status myapp

# Check if process is hung
sudo supervisorctl pid myapp
ps aux | grep <pid>

# Increase stopwaitsecs
# Edit config: stopwaitsecs=60
sudo supervisorctl update

# Force kill if necessary
sudo supervisorctl stop myapp
# If still running:
sudo kill -9 <pid>

# Ensure killasgroup is set
# stopasgroup=true
# killasgroup=true

Issue 5: Logs Not Appearing

Symptom: No output in Supervisor logs

Solution:

# Check log file location
sudo supervisorctl tail myapp

# Verify application writes to stdout/stderr
# Not to files directly

# Check redirect_stderr setting
# redirect_stderr=true

# Verify log directory exists and is writable
ls -la /var/log/supervisor/
sudo chown supervisor:supervisor /var/log/supervisor/

# Check if application is buffering output
# For Python, use unbuffered output:
# command=/usr/bin/python3 -u /opt/myapp/app.py

# Clear log and restart
sudo supervisorctl clear myapp
sudo supervisorctl restart myapp

Issue 6: Configuration Changes Not Applied

Symptom: Modified configuration not taking effect

Solution:

# After modifying configuration:

# 1. Reread configuration
sudo supervisorctl reread

# 2. Update processes
sudo supervisorctl update

# 3. If process still using old config, restart it
sudo supervisorctl restart myapp

# Or restart supervisord entirely
sudo systemctl restart supervisord

# Verify configuration syntax
sudo supervisord -c /etc/supervisor/supervisord.conf -t

# Check which config file is being used
ps aux | grep supervisord

Best Practices

Configuration Best Practices

One Program Per File:

# Instead of one large file, use separate files
/etc/supervisor/conf.d/app1.conf
/etc/supervisor/conf.d/app2.conf
/etc/supervisor/conf.d/workers.conf

Use Environment Variables:

environment=
    DATABASE_URL="%(ENV_DATABASE_URL)s",
    SECRET_KEY="%(ENV_SECRET_KEY)s"

Appropriate Auto-restart Settings:

; For stable applications
autorestart=true

; For applications that should stay stopped if they fail
autorestart=false

; For applications that crash during startup
autorestart=unexpected

Set Reasonable Timeouts:

startsecs=10          ; Application needs 10s to fully start
stopwaitsecs=30       ; Allow 30s for graceful shutdown

Use Priority for Startup Order:

[program:database]
priority=100          ; Start first

[program:webapp]
priority=200          ; Start after database

[program:worker]
priority=300          ; Start last

Security Best Practices

Run Processes as Non-Root Users:

[program:myapp]
user=myappuser
group=myappuser

Secure Web Interface:

[inet_http_server]
port=127.0.0.1:9001   ; Bind to localhost only
username=admin
password=strong_random_password

Protect Configuration Files:

sudo chmod 600 /etc/supervisor/conf.d/*.conf
sudo chown root:root /etc/supervisor/conf.d/*.conf

Use SSH Tunnels for Remote Access:

# Instead of exposing web interface, use SSH tunnel
ssh -L 9001:localhost:9001 user@server

Restrict supervisorctl Access:

# Limit who can run supervisorctl
sudo chown root:supervisor /usr/bin/supervisorctl
sudo chmod 750 /usr/bin/supervisorctl

Logging Best Practices

Configure Log Rotation:

stdout_logfile=/var/log/supervisor/myapp.log
stdout_logfile_maxbytes=50MB
stdout_logfile_backups=10

Separate stdout and stderr:

redirect_stderr=false
stdout_logfile=/var/log/supervisor/myapp-stdout.log
stderr_logfile=/var/log/supervisor/myapp-stderr.log

System-Level Log Rotation:

Create /etc/logrotate.d/supervisor:

/var/log/supervisor/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    missingok
    postrotate
        /usr/bin/supervisorctl reload > /dev/null 2>&1 || true
    endscript
}

Centralized Logging:

Send logs to central logging server:

# Use syslog for forwarding
tail -f /var/log/supervisor/myapp.log | logger -t myapp

Monitoring Best Practices

Regular Health Checks:

#!/bin/bash
# healthcheck.sh

FAILED=$(sudo supervisorctl status | grep -v RUNNING | grep -v STOPPED)

if [ -n "$FAILED" ]; then
    echo "Failed processes detected:"
    echo "$FAILED"
    # Send alert
    echo "$FAILED" | mail -s "Supervisor Alert" [email protected]
fi

Automated Monitoring Script:

#!/bin/bash
# monitor.sh

while true; do
    STATUS=$(sudo supervisorctl status all)

    # Check for FATAL processes
    FATAL=$(echo "$STATUS" | grep FATAL)
    if [ -n "$FATAL" ]; then
        echo "$(date): FATAL processes detected"
        echo "$FATAL"
        # Attempt restart
        sudo supervisorctl restart all
    fi

    sleep 60
done

Integration with Monitoring Tools:

Use Supervisor XML-RPC API:

import xmlrpc.client

server = xmlrpc.client.ServerProxy('http://localhost:9001/RPC2')

# Get all process info
all_procs = server.supervisor.getAllProcessInfo()

for proc in all_procs:
    if proc['state'] != 20:  # 20 = RUNNING
        print(f"Process {proc['name']} is not running: {proc['statename']}")

Deployment Best Practices

Version Control Configuration:

# Keep configs in version control
git init /etc/supervisor
cd /etc/supervisor
git add conf.d/*.conf supervisord.conf
git commit -m "Initial supervisor configuration"

Automated Deployment:

#!/bin/bash
# deploy.sh

# Pull latest code
git pull origin main

# Update dependencies
pip install -r requirements.txt

# Reload supervisor configuration
sudo supervisorctl reread
sudo supervisorctl update

# Restart application
sudo supervisorctl restart myapp

# Verify
sudo supervisorctl status myapp

Zero-Downtime Updates:

# Start new version on different port
sudo supervisorctl start myapp_v2

# Verify new version is healthy
# ... health checks ...

# Update load balancer to new version
# ... update nginx/haproxy ...

# Stop old version
sudo supervisorctl stop myapp_v1

# Rename for next deployment
sudo supervisorctl restart myapp_v2:myapp_v1

Performance Best Practices

Optimize Worker Count:

; For CPU-bound tasks
numprocs=4  ; Match CPU core count

; For I/O-bound tasks
numprocs=16  ; Can exceed core count

Resource Limits:

# Set limits in supervisor config
[program:myapp]
umask=022
priority=999

Monitor Resource Usage:

# Check memory usage
for pid in $(sudo supervisorctl pid all); do
    ps -p $pid -o pid,vsz,rss,%mem,%cpu,cmd
done

Conclusion

Supervisor is an invaluable tool for managing application processes reliably and efficiently. By providing automatic restarts, centralized configuration, comprehensive logging, and simple management interfaces, Supervisor dramatically simplifies process management in production environments.

Key Takeaways:

Reliability: Automatic process monitoring and restarting ensures your applications stay available even after crashes or server reboots.

Simplicity: INI-style configuration files and straightforward command-line tools make Supervisor accessible to developers and operators alike.

Flexibility: Support for process groups, multiple instances, environment variables, and user privileges accommodates diverse application architectures.

Visibility: Centralized logging and status monitoring provide clear insight into application health and behavior.

Production-Ready: When configured according to best practices, Supervisor provides enterprise-grade process management suitable for critical production workloads.

Whether you're managing a single Python web application or orchestrating dozens of microservices, Supervisor provides the tools needed for reliable process management. The examples and best practices in this guide establish a solid foundation for implementing Supervisor in your infrastructure.

As your application ecosystem grows, Supervisor scales with you through process groups, multiple instances, and integration with monitoring tools. Combined with proper logging, monitoring, and deployment practices, Supervisor becomes a cornerstone of reliable application operations.

Remember that process management is just one component of a robust infrastructure. Combine Supervisor with proper monitoring, alerting, logging aggregation, and deployment automation to build truly resilient systems.

Your applications are now under the watchful eye of Supervisor, ready to automatically recover from failures and provide the reliability your users expect. Monitor your processes, iterate on your configuration, and leverage Supervisor's features to build bulletproof application infrastructure.

Supervisor Configuration for Process Management: Complete Application Monitoring Guide

Supervisor Configuration for Process Management: Complete Application Monitoring Guide

Introduction

Why Use Supervisor?

Supervisor vs. Systemd

Common Use Cases

Prerequisites

System Requirements

Software Prerequisites

Application Requirements

Installation

Method 1: Package Manager Installation (Recommended)

Ubuntu/Debian Installation

CentOS/Rocky Linux Installation

Enable and Start Service

Method 2: Python pip Installation

Create Configuration Directory

Create Systemd Service (for pip installation)

Method 3: Docker Container Management

Post-Installation Verification

Configuration

Main Configuration File

[unix_http_server] - UNIX Socket Interface

[inet_http_server] - Web Interface

[supervisord] - Main Process Configuration

[supervisorctl] - Control Interface Configuration

[include] - Include Additional Configuration Files

Program Configuration

Basic Program Configuration

Advanced Program Configuration

Group Configuration

Event Listener Configuration

Apply Configuration Changes

Practical Examples

Example 1: Managing Django Application with Gunicorn

Example 2: Managing Celery Workers

Example 3: Managing Node.js Application

Example 4: Managing Multiple Instances

Example 5: Custom Application Script

Verification

Check Process Status

Monitor Logs

Process Control

Configuration Validation

Web Interface Access

Performance Monitoring

Troubleshooting

Issue 1: Process Won't Start

Issue 2: Process Keeps Restarting

Issue 3: Cannot Connect to Supervisor

Issue 4: Process Won't Stop

Issue 5: Logs Not Appearing

Issue 6: Configuration Changes Not Applied

Best Practices

Configuration Best Practices

Security Best Practices

Logging Best Practices

Monitoring Best Practices

Deployment Best Practices

Performance Best Practices

Conclusion

Latest Video

Get $20 Free Credit