O Que E Um Supervisor

What a supervisor actually is in production systems

A supervisor is a process management tool that keeps your applications running when they crash. Not a fancy one either. Just a background daemon that watches your services, restarts them on failure, and logs output. That's it. Nothing mystical about it. I learned this the hard way around 2019 when a Python API I was running on a cheap DigitalOcean droplet would periodically OOM-kill itself during peak traffic. No supervisor, no problem — except the problem was that nobody noticed it was down for six hours. By the time I checked the logs, three months of cron-driven data pipelines had all failed silently because the upstream service was gone.

o que e um supervisor

At its core, a supervisor is a child process monitor. You configure it with a config file — usually INI format — that tells it what commands to run, under which user, how many processes to spawn, and what to do when they exit. The supervisor daemon (usually called supervisord) runs as root or a privileged user, forks your application processes, and maintains state about their lifecycle. If a process exits with a non-zero code, it restarts it after a configurable delay. The configuration lives at /etc/supervisor/conf.d/ on most Linux systems. Each file in that directory represents one program. Here's what a minimal entry looks like: [program:myapp]
command=python3 /opt/myapp/main.py
directory=/opt/myapp
user=www-data
autostart=true
autorestart=true
stderr_logfile=/var/log/myapp.err.log
stdout_logfile=/var/log/myapp.out.log

That's the entire setup. Start the daemon, point it at your config, and your app is now managed. No systemd complexity, no cron tricks, no hoping you set up health checks correctly. What people miss about supervisors is that they're not just for restarts. They handle log rotation natively through the logreconnect and maxbytes options, which means you don't need a separate logrotate configuration for your application output. They also manage process groups, so if your app spawns child processes, you can configure numprocs and process_name to get multiple instances with names like myapp_00, myapp_01, etc. That's useful when you need horizontal scaling within a single machine without setting up something like Kubernetes. There's a web interface too, built into supervisord by default on port 9001. It's ugly as hell, but it shows you every process state in real time — RUNNING, BACKOFF, FATAL, STOPPING. The supervisorctl CLI is what you'll actually use day to day. supervisorctl status gives you a quick overview. supervisorctl restart myapp does exactly what you think. supervisorctl tail -f myapp stderr streams the error log in real time.

One thing that trips people up: supervisors don't prevent crashes. They only react to them. If your application has a memory leak, supervisord will keep restarting it forever and your machine will eventually fill up with zombie processes and exhausted file descriptors. I had a Node.js service that was leaking approximately 50MB per hour. Supervisor kept restarting it every time it hit the configured exit code threshold, but the restarts got shorter and shorter as the system ran out of memory. The fix wasn't better supervision — it was fixing the leak. Supervisor just made the symptom less visible. Another edge case: when you have dependency chains. Say your Python app needs a PostgreSQL connection, and PostgreSQL restarts unexpectedly. Supervisor will restart your app, but if PostgreSQL isn't fully ready yet, your app will crash again on startup, triggering another restart, and you'll end up in a BACKOFF loop. The solution is to set startsecs=10 in your config, which tells supervisor that a process needs to stay running for at least 10 seconds before it's considered successfully started. This prevents premature restart cycles. You also want startretries=3 so it doesn't give up after one bad launch. For anything production-critical, I'd recommend combining supervisor with a simple health check wrapper. Wrap your application's entry point in a script that runs a quick connectivity test before executing the real command. If PostgreSQL isn't accepting connections, exit with code 1 immediately instead of letting the app spin for 30 seconds before crashing. Supervisor then treats it as a clean failure and retries after the configured delay.

The main downside is that supervisor is not designed for orchestration across multiple machines. If you need that, you're looking at Kubernetes, Docker Swarm, or at minimum systemd with a proper cluster manager. Supervisor is a single-machine tool. It works great inside a container or VM, but it doesn't replicate state or coordinate between nodes. Trying to run the same supervisor config on five different servers and expecting them to work together is a mistake I've seen people make. Also worth noting: supervisor's configuration format is static. There's no dynamic config reloading in the traditional sense. If you change a config file, you need to run supervisorctl reread followed by supervisorctl update. The update command only restarts programs whose configuration actually changed, which is convenient, but if you forget these steps after editing a config, you'll spend twenty minutes wondering why your changes aren't taking effect. Installation is straightforward on Debian-based systems: apt install supervisor. On RHEL/CentOS it's yum install supervisor. The package includes both the daemon and the CLI tools. After installation, enable it with systemctl enable supervisord so it starts on boot, then drop your config files into /etc/supervisor/conf.d/ and run supervisorctl reread and supervisorctl update.

That's really all there is to it. It's unglamorous, it doesn't have a dashboard that looks like something from a sci-fi movie, and it won't save you from bad code. But for keeping individual services alive on a single machine, it's been reliable enough that I've used it in production for years without a single incident that was actually supervisor's fault.