BLOG POSTS
    MangoHost Blog / How to Install and Manage Supervisor on Ubuntu and Debian VPS
How to Install and Manage Supervisor on Ubuntu and Debian VPS

How to Install and Manage Supervisor on Ubuntu and Debian VPS

Supervisor is a process control system that provides a client/server architecture for monitoring and managing processes on Unix-based systems, making it essential for maintaining long-running applications, background tasks, and services on your VPS. Instead of relying on manual process management or basic init scripts, Supervisor offers automatic restarts, logging, process grouping, and web-based monitoring capabilities that can save hours of debugging and maintenance work. In this comprehensive guide, you’ll learn how to install Supervisor on Ubuntu and Debian systems, configure it for various use cases, manage processes effectively, and troubleshoot common issues that arise in production environments.

How Supervisor Works Under the Hood

Supervisor operates as a daemon process that spawns and monitors child processes based on configuration files. Unlike systemd or other init systems, Supervisor expects programs to run in the foreground rather than daemonizing themselves. This approach provides several advantages:

  • Direct control over process lifecycle without dealing with PID files
  • Immediate process restart capabilities when programs crash
  • Built-in logging with automatic rotation
  • XML-RPC interface for programmatic control
  • Web interface for visual monitoring and management

The architecture consists three main components: supervisord (the server), supervisorctl (command line client), and optional web interface. The server reads configuration files from /etc/supervisor/conf.d/ and maintains persistent connections to managed processes, capturing stdout/stderr streams for logging purposes.

Installation and Initial Setup

Installing Supervisor on Ubuntu and Debian systems can be accomplished through multiple methods. The package manager approach provides the most stable experience for production environments:

# Update package repositories
sudo apt update

# Install Supervisor
sudo apt install supervisor

# Verify installation
supervisord --version

# Start and enable Supervisor service
sudo systemctl start supervisor
sudo systemctl enable supervisor

# Check service status
sudo systemctl status supervisor

For systems requiring the latest features, you can install via pip instead:

# Install pip if not available
sudo apt install python3-pip

# Install Supervisor via pip
sudo pip3 install supervisor

# Create configuration directory
sudo mkdir -p /etc/supervisor/conf.d

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

The default configuration file resides at /etc/supervisor/supervisord.conf and includes basic settings for the daemon, web interface, and include directive for additional configuration files:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

[supervisord]
logfile=/var/log/supervisor/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

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

Step-by-Step Process Management Configuration

Creating effective Supervisor configurations requires understanding the available options and their impact on process behavior. Here’s a comprehensive example for managing a Node.js application:

# Create configuration file: /etc/supervisor/conf.d/nodeapp.conf
[program:nodeapp]
command=/usr/bin/node /var/www/app/server.js
directory=/var/www/app
autostart=true
autorestart=true
startretries=3
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/supervisor/nodeapp.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5
environment=NODE_ENV=production,PORT=3000

Key configuration parameters and their purposes:

Parameter Purpose Default Value Example Usage
command Full command to execute Required /usr/bin/python3 /app/worker.py
directory Working directory /tmp /var/www/application
autostart Start on supervisor boot true true/false
autorestart Restart policy unexpected true/false/unexpected
user Process owner supervisord user www-data, ubuntu
numprocs Number of processes 1 4 (for scaling)

After creating configuration files, reload Supervisor to apply changes:

# Reload configuration
sudo supervisorctl reread

# Add new programs
sudo supervisorctl update

# Start specific program
sudo supervisorctl start nodeapp

# Check status
sudo supervisorctl status

Real-World Examples and Use Cases

Supervisor excels in various scenarios where process reliability and monitoring are crucial. Here are practical configurations for common deployment patterns:

Multiple Worker Processes

For CPU-intensive applications, you can spawn multiple worker instances:

[program:worker]
command=/usr/bin/python3 /app/worker.py --worker-id=%(process_num)s
directory=/app
numprocs=4
process_name=worker_%(process_num)s
autostart=true
autorestart=true
user=appuser
redirect_stderr=true
stdout_logfile=/var/log/supervisor/worker_%(process_num)s.log

Message Queue Consumer

Redis or RabbitMQ consumers benefit from automatic restart capabilities:

[program:queue_consumer]
command=/usr/bin/python3 /app/consume.py
directory=/app
autostart=true
autorestart=true
startretries=10
user=queueuser
redirect_stderr=true
stdout_logfile=/var/log/supervisor/consumer.log
stderr_logfile=/var/log/supervisor/consumer_error.log
environment=REDIS_URL="redis://localhost:6379",QUEUE_NAME="tasks"
stopsignal=TERM
stopwaitsecs=30

Development Environment with Hot Reload

For development workflows, you might want different restart behaviors:

[program:dev_server]
command=/usr/bin/python3 manage.py runserver 0.0.0.0:8000
directory=/home/developer/project
autostart=false
autorestart=false
user=developer
redirect_stderr=true
stdout_logfile=/tmp/dev_server.log
environment=DEBUG="True",DATABASE_URL="sqlite:///db.sqlite3"

Comparison with Alternative Process Managers

Understanding when to choose Supervisor over other process management solutions helps make informed architectural decisions:

Feature Supervisor systemd PM2 Docker
Learning Curve Low Medium Low (Node.js) High
Web Interface Built-in No Yes External tools
Log Management Automatic rotation journald Built-in External logging
Resource Isolation Process level cgroups Process level Container level
Clustering Manual No Built-in Orchestration needed
Memory Usage ~10MB System service ~20MB Variable

Supervisor works exceptionally well for:

  • Legacy applications that don’t integrate well with systemd
  • Development environments requiring frequent process restarts
  • Applications needing detailed process monitoring and logging
  • Multi-tenant environments where process isolation is important
  • Situations requiring programmatic process control via XML-RPC

Advanced Management and Monitoring

The supervisorctl command provides comprehensive process management capabilities beyond basic start/stop operations:

# Show detailed status with uptime and PID
sudo supervisorctl status

# Start all processes
sudo supervisorctl start all

# Stop specific process group
sudo supervisorctl stop worker:*

# Restart with configuration reload
sudo supervisorctl restart nodeapp

# View process logs in real-time
sudo supervisorctl tail -f nodeapp

# Clear log files
sudo supervisorctl clear nodeapp

# Signal processes (useful for graceful shutdowns)
sudo supervisorctl signal HUP nodeapp

For web-based monitoring, enable the inet_http_server in supervisord.conf:

[inet_http_server]
port=127.0.0.1:9001
username=admin
password=secretpassword

# Access via: http://your-server:9001

The XML-RPC interface allows programmatic control through Python scripts:

#!/usr/bin/env python3
import xmlrpc.client

server = xmlrpc.client.Server('http://admin:secretpassword@localhost:9001/RPC2')

# Get all process info
processes = server.supervisor.getAllProcessInfo()
for proc in processes:
    print(f"Process: {proc['name']}, State: {proc['statename']}")

# Start a specific process
result = server.supervisor.startProcess('nodeapp')
print(f"Start result: {result}")

Best Practices and Security Considerations

Implementing Supervisor securely requires attention to several configuration aspects and operational practices:

Security Configuration

# Secure supervisord.conf settings
[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700
chown=root:supervisor

[supervisord]
user=root
logfile=/var/log/supervisor/supervisord.log
logfile_maxbytes=50MB
logfile_backups=10
loglevel=info
pidfile=/var/run/supervisord.pid
nodaemon=false
minfds=1024
minprocs=200

Resource Management

Prevent resource exhaustion through proper limits:

[program:resource_limited_app]
command=/usr/bin/python3 /app/processor.py
directory=/app
user=appuser
autostart=true
autorestart=true
startretries=3
redirect_stderr=true
stdout_logfile=/var/log/supervisor/processor.log
priority=999
startsecs=10
stopwaitsecs=600
killasgroup=true
stopasgroup=true

Log Management Strategy

Implement proper log rotation to prevent disk space issues:

# Configure logrotate for Supervisor logs
# /etc/logrotate.d/supervisor
/var/log/supervisor/*.log {
    daily
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 0644 root root
    postrotate
        supervisorctl signal USR2 > /dev/null 2>&1 || true
    endscript
}

Troubleshooting Common Issues

Several issues frequently occur when working with Supervisor, particularly around process startup, permission handling, and resource conflicts:

Process Won’t Start

Check supervisord logs and process-specific logs for error details:

# View supervisord daemon logs
sudo tail -f /var/log/supervisor/supervisord.log

# Check specific process logs
sudo supervisorctl tail nodeapp stderr

# Verify file permissions
ls -la /var/www/app/server.js
sudo -u www-data /usr/bin/node /var/www/app/server.js

Permission Denied Errors

Common permission issues and solutions:

# Fix socket permissions
sudo chmod 755 /var/run/
sudo chown root:supervisor /var/run/supervisor.sock

# Verify user can execute command
sudo -u appuser /usr/bin/python3 /app/worker.py

# Check directory permissions
sudo chown -R appuser:appuser /app
sudo chmod -R 755 /app

Environment Variable Issues

Environment problems often manifest as import errors or configuration issues:

# Debug environment in process configuration
[program:debug_env]
command=/bin/bash -c "env > /tmp/supervisor_env.txt && /usr/bin/python3 /app/main.py"
environment=PATH="/usr/local/bin:/usr/bin:/bin",PYTHONPATH="/app:/app/lib"

Process Restart Loops

Prevent rapid restart loops that can consume system resources:

[program:stable_app]
command=/usr/bin/python3 /app/main.py
autostart=true
autorestart=true
startretries=3
startsecs=10
exitcodes=0,2
stopsignal=TERM
stopwaitsecs=10
redirect_stderr=true
stdout_logfile=/var/log/supervisor/app.log

Monitor restart patterns through logs:

# Count recent restarts
sudo grep "entered RUNNING state" /var/log/supervisor/supervisord.log | tail -20

# Check for specific error patterns
sudo grep "FATAL" /var/log/supervisor/supervisord.log

Performance Optimization and Monitoring

Supervisor itself has minimal performance impact, but proper configuration can optimize managed process performance:

Memory and CPU Monitoring

#!/bin/bash
# supervisor_monitor.sh - Basic performance monitoring script
echo "Supervisor Process Information:"
ps aux | grep -E "(supervisord|nodeapp|worker)" | grep -v grep

echo -e "\nMemory Usage:"
ps -o pid,ppid,user,%cpu,%mem,cmd -p $(pgrep -f supervisor)

echo -e "\nLog File Sizes:"
du -h /var/log/supervisor/*.log

Scaling Configuration

For high-load scenarios, optimize Supervisor settings:

[supervisord]
minfds=4096
minprocs=1000
childlogdir=/var/log/supervisor
strip_ansi=false
silent=false

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

# Increase system limits if needed
# /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536

Performance benchmarks show Supervisor can efficiently manage hundreds of processes on modern VPS instances, with typical memory overhead of 10-15MB plus 2-3MB per managed process. The XML-RPC interface handles approximately 1000 requests per second on standard hardware, making it suitable for automated deployment and monitoring systems.

For additional information and advanced configuration options, consult the official Supervisor documentation at http://supervisord.org/configuration.html and the community-maintained configuration examples repository. Regular monitoring of process health, log rotation, and system resource usage ensures optimal performance in production environments.



This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.

Leave a reply

Your email address will not be published. Required fields are marked