Chapter 1. Using Supervisor

Table of Contents

1.1. Introduction
1.1.1. Overview
1.1.2. Supervisor Components
1.1.3. Platform Requirements
1.2. Installing
1.2.1. Installing To A System With Internet Access
1.2.2. Installing To A System Without Internet Access
1.2.3. Creating A Configuration File
1.3. Running Supervisor
1.3.1. Adding a Program
1.3.2. Running Supervisord
1.3.3. Running Supervisorctl
1.3.4. Signals
1.3.5. Runtime Security
1.4. Configuration File Syntax and Semantics
1.4.1. [unix_http_server] Section Settings
1.4.2. [inet_http_server] Section Settings
1.4.3. [supervisord] Section Settings
1.4.4. [supervisorctl] Section Settings
1.4.5. [program:x] Section Settings
1.4.6. [include] Section Settings
1.4.7. [group:x] Section Settings
1.4.8. [eventlister:x] Section Settings
1.4.9. [rpcinterface:x] Section Settings
1.5. Subprocesses
1.5.1. Nondaemonizing of Subprocesses
1.5.2. pidproxy Program
1.5.3. Subprocess Environment
1.5.4. Process States
1.6. Logging
1.6.1. Activity Log
1.6.2. Child Process Logs
1.7. Events
1.7.1. Event Listeners and Event Notifications
1.7.2. Configuring an Event Listener
1.7.3. Writing an Event Listener
1.7.4. Event Types
1.8. Extending Supervisor's XML-RPC API
1.8.1. Configuring XML-RPC Interface Factories
1.9. memmon Memory Monitor Event Listener
1.9.1. Description
1.9.2. The memmon Command
1.9.3. Configuring Memmon Into the Supervisor Config
1.10. Upgrading From Older Releases
1.10.1. Upgrading from Supervisor 2 to Supervisor 3
1.11. Frequently Asked Questions
1.12. Development of Supervisor
1.12.1. Development Resources
1.12.2. Contributing
1.12.3. Sponsoring
1.12.4. Author Information

1.1. Introduction

1.1.1. Overview

The supervisor is a client/server system that allows its users to control a number of processes on UNIX-like operating systems. It was inspired by the following:

  • It is often inconvenient to need to write "rc.d" scripts for every single process instance. rc.d scripts are a great lowest-common-denominator form of process initialization/autostart/management, but they can be painful to write and maintain. Additionally, rc.d scripts cannot automatically restart a crashed process and many programs do not restart themselves properly on a crash. Supervisord starts processes as its subprocesses, and can be configured to automatically restart them on a crash. It can also automatically be configured to start processes on its own invocation.

  • It's often difficult to get accurate up/down status on processes on UNIX. Pidfiles often lie. Supervisord starts processes as subprocesses, so it always knows the true up/down status of its children and can be queried conveniently for this data.

  • Users who need to control process state often need only to do that. They don't want or need full-blown shell access to the machine on which the processes are running. Supervisorctl allows a very limited form of access to the machine, essentially allowing users to see process status and control supervisord-controlled subprocesses by emitting "stop", "start", and "restart" commands from a simple shell or web UI.

  • Users often need to control processes on many machines. Supervisor provides a simple, secure, and uniform mechanism for interactively and automatically controlling processes on groups of machines.

  • Processes which listen on "low" TCP ports often need to be started and restarted as the root user (a UNIX misfeature). It's usually the case that it's perfectly fine to allow "normal" people to stop or restart such a process, but providing them with shell access is often impractical, and providing them with root access or sudo access is often impossible. It's also (rightly) difficult to explain to them why this problem exists. If supervisord is started as root, it is possible to allow "normal" users to control such processes without needing to explain the intricacies of the problem to them.

  • Processes often need to be started and stopped in groups, sometimes even in a "priority order". It's often difficult to explain to people how to do this. Supervisor allows you to assign priorities to processes, and allows user to emit commands via the supervisorctl client like "start all", and "restart all", which starts them in the preassigned priority order. Additionally, processes can be grouped into "process groups" and a set of logically related processes can be stopped and started as a unit.

1.1.2. Supervisor Components

supervisord

The server piece of the supervisor is named supervisord. It is responsible for starting programs at its own invocation, responding to commands from clients, restarting crashed or exited subprocesseses, logging its subprocess stdout and stderr output, and generating and handling "events" corresponding to points in subprocess lifetimes. It is meant to be run as the root user in most production setups.

[Note] Note

See "Security Notes" elsewhere document for caveats!

The server process uses a configuration file. This is typically located in /etc/supervisord.conf. This configuration file is an "Windows-INI" style config file. It is important to keep this file secure via proper filesystem permissions because it may contain unencrypted usernames and passwords.

supervisorctl

The command-line client piece of the supervisor is named supervisorctl. It provides a shell-like interface to the features provided by supervisord. From supervisorctl, a user can connect to different supervisord processes, get status on the subprocesses controlled by, stop and start subprocesses of, and get lists of running processes of a supervisord.

The command-line client talks to the server across a UNIX domain socket or an internet (TCP) socket. The server can assert that the user of a client should present authentication credentials before it allows him to perform commands. The client process typically uses the same configuration file as the server but any configuration file with a [supervisorctl] section in it will work.

Web Server

A (sparse) web user interface with functionality comparable to supervisorctl may be accessed via a browser if you start supervisord against an internet socket. Visit the server URL (e.g. http://localhost:9001/) to view and control process status through the web interface after activating the configuration file's [inet_http_server] section.

XML-RPC Interface

The same HTTP server which serves the web UI serves up an XML-RPC interface that can be used to interrogate and control supervisor and the programs it runs. To use the XML-RPC interface, connect to supervisor's http port with any XML-RPC client library and run commands against it. An example of doing this using Python's xmlrpclib client library is as follows.

import xmlrpclib
server = xmlrpclib.Server('http://localhost:9001')
          

You may call methods against the supervisord and its subprocesses by using the supervisor namespace. An example is provided below.

server.supervisor.getState()
          

You can get a list of methods supported by supervisord's XML-RPC interface by using the XML-RPC system.listMethods API::

server.system.listMethods()
          

You can see help on a method by using the system.methodHelp API against the method.

print server.system.methodHelp('supervisor.shutdown')
          

supervisord's XML-RPC interface also supports the nascent XML-RPC multicall API described at http://www.xmlrpc.com/discuss/msgReader$1208.

You can extend supervisord functionality with new XML-RPC API methods by adding new top-level RPC interfaces as necessary. See "Configuration File [rpcinterface:x] Section Settings" elsewhere in this document.

1.1.3. Platform Requirements

Supervisor has been tested and is known to run on Linux (Ubuntu Dapper/Feisy/Gutsy), Mac OS X (10.4/10.5), and Solaris (10 for Intel) and FreeBSD 6.1. It will likely work fine on most UNIX systems.

Supervisor will not run at all under any version of Windows.

Supervisor is known to work with Python 2.3.3 or better, and it may work with Python 2.3.0, Python 2.3.1 and Python 2.3.2 (although these have not been tested). It will not work under Python versions 2.2 or before.