Supervisor 4.2.1

Running supervisord¶

To start supervisord, run . The
resulting process will daemonize itself and detach from the terminal.
It keeps an operations log at by default.

You may start the supervisord executable in the foreground
by passing the flag on its command line. This is useful to
debug startup problems.

Warning

When supervisord starts up, it will search for its
configuration file in default locations including the current working
directory. If you are security-conscious you will probably want to
specify a “-c” argument after the supervisord command
specifying an absolute path to a configuration file to ensure that someone
doesn’t trick you into running supervisor from within a directory that
contains a rogue file. A warning is emitted when
supervisor is started as root without this argument.

To change the set of programs controlled by supervisord,
edit the file and or otherwise
restart the supervisord process. This file has several
example program definitions.

The supervisord command accepts a number of command-line
options. Each of these command line options overrides any equivalent
value in the configuration file.

WebSupervisor

WebSupervisor is a cloud-based system designed for monitoring, data analysing and management of ComAp and 3rd party devices via the Internet.

The system also offers powerful reporting and sophisticated analysis tools such as the Alarm Analyser, trends and heat maps that give you additional added value and help you to:

• optimize revenue for fleet of gen-sets
• increase gen-set up-time
• reduce maintenance cost

Security is the top priority with WebSupervisor. It runs on Microsoft Azure servers, which are some of the most popular and secure servers in the world and it passed security audit by independent authority.

Basic configuration

Open the file and check its contents. You will note that this configuration file follows the syntax, and it is divided by sections (representend by brackets as in ).

To add programs to be managed by supervisor we just need to create the appropriate sections. However, to avoid messing arround with the main configuration file every time we need to add (or change) a program, we will be using the section. Find this section, uncomment it and then edit it to look like the following.

Now for each program we want to add, we will be creating a file inside the directory. Lets create this folder.

Starting the supervisor server

As noted before, supervisor is composed of a server and clients that connect to it. To be able to manage and control programs, we need to start the server. To do so, we will be registering the supervisor server in , so that the server may be started at system startup.

To do so, create a file called in the directory.

Add the following contents to the file.

Activate the supervisord service.

As long as the service file is located in the directory, it will be automatically started at system startup.

You can check the status of the service.

Also, you can check out the logs.

Adding programs

The programs controlled by supervisor are given by different sections in the configuration. For each program we want to manage, we will create a standalone configuration file informing the command executable path, any environmental variables, how to perform in case of a shutdown.

First, let’s create a simple script that logs a timestamp. Create a file called (anywhere you wish, we will be referencing the full path of this script).

Now, put the following contents into it

Now make it executable

In practical terms this script is pretty much useless. However, we can use it to demonstrate the power of supervisor. Create the corresponding configuration file by running the following.

Now put the following contents into this file.

Note: Be sure to replace with your username.

We will review this configuration step by step.

First, the configuration begins by defining a program of name hello_supervisor. It also informs the full path of the executable to be run.

This line states that this program should be automaticaly started when supervisor is started.

If the program quits, for any reason, this line informs supervisor to automatically restart the process.

These lines define the logfile location for and , respectively.

Managing programs

Now that we have installed and configured supervisor, we are able to manage our processes.

After adding a new program, we should run the following two commands, to inform the server to reread the configuration files and to apply any changes.

Now execute the client.

You will be greeted with a list of the registered proccesses. You will see a proccess called with a status.

Type for a list of avaialable commands.

In a nutshell, we can , and programs by passing the program name as an argument to the respective command.

We can also take a look at the program output with the command.

For the output, you can use as well.

By invoking the command, you can view the status of all registered programs.

Once you are finished, you can quit.

The webserver client

To allow access to the supervisord webserver, open the supervisord configuration file and locate the section.

Now update this section’s configuration with the following.

Replace and with your desired credentials, save your modifications and the restart supervisord service.

Remember to allow access to the port on your firewall and then access from your browser. When asked, provide your and . You can now control your proccesses from web.

Conclusion

We have installed the most up-to-date version of supervisord, learned how to configure it for system auto-start with systemd and also reviewed a basic usage of . For more advanced configuration and use cases you may refer to the official supervisord documentation.

Process States¶

A process controlled by supervisord will be in one of the below states
at any given time. You may see these state names in various user
interface elements in clients.

(0)

(10)

(20)

(30)

(40)

(100)

(200)

(1000)

Each process run under supervisor progresses through these states as
per the following directed graph.

Subprocess State Transition Graph

A process is in the state if it has been stopped
adminstratively or if it has never been started.

When an autorestarting process is in the state, it will be
automatically restarted by supervisord. It will switch
between and states until it becomes evident
that it cannot be started because the number of has
exceeded the maximum, at which point it will transition to the
state. Each start retry will take progressively
more time.

When a process is in the state, it will
automatically restart:

• never if its parameter is set to .
• unconditionally if its parameter is set to .
• conditionally if its parameter is set to
  . If it exited with an exit code that doesn’t match
  one of the exit codes defined in the configuration
  parameter for the process, it will be restarted.

A process automatically transitions from to as
a result of being configured to autorestart conditionally or
unconditionally. The number of transitions between and
is not limited in any way: it is possible to create a
configuration that endlessly restarts an exited process. This is a
feature, not a bug.

An autorestarted process will never be automatically restarted if it
ends up in the state (it must be manually restarted from
this state).

A process transitions into the state via an
administrative stop request, and will then end up in the
state.

A process that cannot be stopped successfully will stay in the
state forever. This situation should never be reached
during normal operations as it implies that the process did not
respond to a final signal sent to it by supervisor, which
is “impossible” under UNIX.

State transitions which always require user action to invoke are
these:

->

->

State transitions which typically, but not always, require user
action to invoke are these, with exceptions noted:

-> (except at supervisord startup if process
is configured to autostart)

-> (except if process is configured to
autorestart)

All other state transitions are managed by supervisord automatically.

Running supervisorctl¶

To start supervisorctl, run . A
shell will be presented that will allow you to control the processes
that are currently managed by supervisord. Type “help” at
the prompt to get information about the supported commands.

The supervisorctl executable may be invoked with “one time”
commands when invoked with arguments from a command line. An example:
. If arguments are present on the
command-line, it will prevent the interactive shell from being
invoked. Instead, the command will be executed and
will exit with a code of 0 for success or running and non-zero for
error. An example: would return non-zero
if any single process was not running.

If supervisorctl is invoked in interactive mode against a
supervisord that requires authentication, you will be asked
for authentication credentials.

supervisorctl Command-Line Options

action

Actions are commands like “tail” or “stop”. If -i is specified or no action is
specified on the command line, a “shell” interpreting actions typed
interactively is started. Use the action “help” to find out about available
actions.

Installation

Installation of Supervisor on both Ubuntu and Debian is incredibly simple, as prebuilt packages already exist within both distributions’ repositories.

As the root user, run the following command to install the Supervisor package:

apt-get install supervisor

Once this has completed, the supervisor daemon should already be started, as the prebuilt packages come with an init script that will also ensure the Supervisor is restarted after a system reboot. You can ensure this is the case by running:

service supervisor restart

Now that we have Supervisor installed, we can look at adding our first programs.

[fcgi-program:x] Section Settings¶

Supervisor can manage groups of FastCGI
processes that all listen on the same socket. Until now, deployment
flexibility for FastCGI was limited. To get full process management,
you could use mod_fastcgi under Apache but then you were stuck with
Apache’s inefficient concurrency model of one process or thread per
connection. In addition to requiring more CPU and memory resources,
the process/thread per connection model can be quickly saturated by a
slow resource, preventing other resources from being served. In order
to take advantage of newer event-driven web servers such as lighttpd
or nginx which don’t include a built-in process manager, you had to
use scripts like cgi-fcgi or spawn-fcgi. These can be used in
conjunction with a process manager such as supervisord or daemontools
but require each FastCGI child process to bind to its own socket.
The disadvantages of this are: unnecessarily complicated web server
configuration, ungraceful restarts, and reduced fault tolerance. With
fewer sockets to configure, web server configurations are much smaller
if groups of FastCGI processes can share sockets. Shared sockets
allow for graceful restarts because the socket remains bound by the
parent process while any of the child processes are being restarted.
Finally, shared sockets are more fault tolerant because if a given
process fails, other processes can continue to serve inbound
connections.

With integrated FastCGI spawning support, Supervisor gives you the
best of both worlds. You get full-featured process management with
groups of FastCGI processes sharing sockets without being tied to a
particular web server. It’s a clean separation of concerns, allowing
the web server and the process manager to each do what they do best.

Note

The socket manager in Supervisor was originally developed to support
FastCGI processes but it is not limited to FastCGI. Other protocols may
be used as well with no special configuration. Any program that can
access an open socket from a file descriptor (e.g. with

in Python) can use the socket manager. Supervisor will automatically
create the socket, bind, and listen before forking the first child in a
group. The socket will be passed to each child on file descriptor
number (zero). When the last child in the group exits,
Supervisor will close the socket.

All the options available to sections are
also respected by sections.

Section Values

sections have a few keys which
sections do not have.

Consult for other allowable keys, delta the
above constraints and additions.

Installing To A System Without Internet Access¶

If the system that you want to install Supervisor to does not have
Internet access, you’ll need to perform installation slightly
differently. Since both and depend on internet access to perform downloads of dependent
software, neither will work on machines without internet access until
dependencies are installed. To install to a machine which is not
internet-connected, obtain the following dependencies on a machine
which is internet-connected:

• setuptools (latest) from https://pypi.org/pypi/setuptools/.
• meld3 (latest) from https://pypi.org/pypi/meld3/.

Copy these files to removable media and put them on the target
machine. Install each onto the target machine as per its
instructions. This typically just means unpacking each file and
invoking in the unpacked directory.
Finally, run supervisor’s .

[rpcinterface:x] Section Settings¶

Adding settings in the configuration file is only
useful for people who wish to extend supervisor with additional custom
behavior.

In the sample config file, there is a section which is named
. By default it looks like the
following.

supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

The section must remain in the
configuration for the standard setup of supervisor to work properly.
If you don’t want supervisor to do anything it doesn’t already do out
of the box, this is all you need to know about this type of section.

However, if you wish to add rpc interface namespaces in order to
customize supervisor, you may add additional
sections, where “foo” represents the namespace of the interface (from
the web root), and the value named by
is a factory callable which should
have a function signature that accepts a single positional argument
and as many keyword arguments as required to perform
configuration. Any extra key/value pairs defined within the
section will be passed as keyword arguments to
the factory.

Here’s an example of a factory function, created in the
file of the Python package .

from my.package.rpcinterface import AnotherRPCInterface

def make_another_rpcinterface(supervisord, **config):
    retries = int(config.get('retries', ))
    another_rpc_interface = AnotherRPCInterface(supervisord, retries)
    return another_rpc_interface

And a section in the config file meant to configure it.

Child Process Logs¶

The stdout of child processes spawned by supervisor, by default, is
captured for redisplay to users of supervisorctl and other
clients. If no specific logfile-related configuration is performed in
a , , or
section in the configuration file, the following is true:

• supervisord will capture the child process’ stdout and
  stderr output into temporary files. Each stream is captured to a
  separate file. This is known as log mode.
• log files are named automatically and placed in the
  directory configured as of the
  section of the config file.
• The size of each log file is bounded by the
  value of the program section
  (where {streamname} is “stdout” or “stderr”). When it reaches that
  number, it is rotated (like the activity log), based on the
  .

The configuration keys that influence child process logging in
and sections are these:

, , ,
, , ,
, ,
, , and
.

sections may not specify
, , or
, but otherwise they accept the same values.

The configuration keys that influence child process logging in the
config file section are these:
, and .

Capture Mode

Capture mode is an advanced feature of Supervisor. You needn’t
understand capture mode unless you want to take actions based on data
parsed from subprocess output.

If a section in the configuration file defines a
non-zero or
parameter, each process represented by the program section may emit
special tokens on its stdout or stderr stream (respectively) which
will effectively cause supervisor to emit a
event (see for a description of events).

The process communications protocol relies on two tags, one which
commands supervisor to enter “capture mode” for the stream and one
which commands it to exit. When a process stream enters “capture
mode”, data sent to the stream will be sent to a separate buffer in
memory, the “capture buffer”, which is allowed to contain a maximum of
bytes. During capture mode, when the buffer’s
length exceeds bytes, the earliest data in the
buffer is discarded to make room for new data. When a process stream
exits capture mode, a event subtype is
emitted by supervisor, which may be intercepted by event listeners.

The tag to begin “capture mode” in a process stream is
. The tag to exit capture mode is
. The data between these tags may be
arbitrary, and forms the payload of the
event. For example, if a program is set up with a
of “1MB”, and it emits the following on
its stdout stream:

<!--XSUPERVISOR:BEGIN-->Hello!<!--XSUPERVISOR:END-->

In this circumstance, supervisord will emit a
event with data in the payload of
“Hello!”.

An example of a script (written in Python) which emits a process
communication event is in the directory of the
supervisor package, named .

The output of processes specified as “event listeners”
( sections) is not processed this way.
Output from these processes cannot enter capture mode.

Nondaemonizing of Subprocesses¶

Programs meant to be run under supervisor should not daemonize
themselves. Instead, they should run in the foreground. They should
not detach from the terminal from which they are started.

The easiest way to tell if a program will run in the foreground is to
run the command that invokes the program from a shell prompt. If it
gives you control of the terminal back, but continues running, it’s
daemonizing itself and that will almost certainly be the wrong way to
run it under supervisor. You want to run a command that essentially
requires you to press Ctrl-C to get control of the terminal
back. If it gives you a shell prompt back after running it without
needing to press Ctrl-C, it’s not useful under supervisor. All
programs have options to be run in the foreground but there’s no
“standard way” to do it; you’ll need to read the documentation for
each program.

Below are configuration file examples that are known to start
common programs in “foreground” mode under Supervisor.

Two Zope 2.X instances and one ZEO server

command=/path/to/runzeo
priority=1


command=/path/to/instance/home/bin/runzope
priority=2
redirect_stderr=true


command=/path/to/another/instance/home/bin/runzope
priority=2
redirect_stderr=true

Postgres 8.X

command=/path/to/postmaster
; we use the "fast" shutdown signal SIGINT
stopsignal=INT
redirect_stderr=true

Surpervisor的启动

1234

# supervisord二进制启动supervisord -c /etc/supervisord.conf# 检查进程ps aux | grep supervisord

或者以systemd的方式管理

vi /etc/rc.d/init.d/supervisord

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162

#!/bin/sh## /etc/rc.d/init.d/supervisord## Supervisor is a client/server system that# allows its users to monitor and control a# number of processes on UNIX-like operating# systems.## chkconfig: - 64 36# description: Supervisor Server# processname: supervisord# Source init functions. /etc/rc.d/init.d/functionsprog="supervisord"prefix="/usr"exec_prefix="${prefix}"prog_bin="${exec_prefix}/bin/supervisord"PIDFILE="/var/run/$prog.pid"start(){       echo -n $"Starting $prog: "       daemon $prog_bin --pidfile $PIDFILE -c /etc/supervisord.conf        && success $"$prog startup" || failure $"$prog startup"       echo}stop(){       echo -n $"Shutting down $prog: "        && killproc $prog || success $"$prog shutdown"       echo}case "$1" in start)   start ;; stop)   stop ;; status)       status $prog ;; restart)   stop   start ;; *)   echo "Usage: $0 {start|stop|restart|status}" ;;esac

设置开机启动及systemd方式启动。

1234

sudo chmod +x /etc/rc.d/init.d/supervisordsudo chkconfig --add supervisordsudo chkconfig supervisord onsudo service supervisord start

Установка

sudo aptitude update
sudo aptitude install supervisor

Общая настройка демона supervisor

Откроем для редактирования основной конфиг supervisor

mcedit /etc/supervisor/supervisord.conf

и приведем к виду:

file=/var/run/supervisor.sock 
chmod=0400 
chown=root:root ; только root сможет использовать supervisorctl 
#username=user
#password={SHA}5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8


port = 192.168.10.1:9988
username = user
password = {SHA}5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8


logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes = 10MB
logfile_backups=10
loglevel = info
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor 


supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface


serverurl=unix:///var/run/supervisor.sock

files = /etc/supervisor/conf.d/*.conf

Подробнее см. на http://supervisord.org/configuration.html

Получаем хэш SHA-1 пароля для доступа через supervisorctl и http.

echo -n your_password | sha1sum | awk '{print $1}'

Сценарии управления процессами

В каталоге /etc/supervisor/supervisor.d/ по умолчанию находятся файлы со сценариями запуска и управления приложениями через  supervisor.

Пример конфигурационного файла supervisor для запуска двух процессов shadowsocks:

command=sslocal --user shadowsocks -qq -c /etc/shadowsocks/shadowsocks_%(process_num)s.conf
process_name=%(program_name)s_%(process_num)d
numprocs=2
startsecs=0
stopwaitsecs=0
autostart=true
autorestart=true
redirect_stderr=true
user=root
stdout_logfile=/var/log/shadowsocks/%(program_name)s_%(process_num)d.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5

#stderr_logfile=/var/log/shadowsocks/stderr_%(program_name)s_%(process_num)d.log
stderr_logfile_maxbytes=10MB
stderr_logfile_backups=5

Adding a Program

New programs are given to Supervisor through configuration files, which inform it of the executable to run, any environmental variables, and how output should be handled.

Note: All programs run under Supervisor must be run in a (sometimes also called ‘foreground mode’). If, by default, the program forks and returns on startup, then you may need to consult the program’s manual to find the option to enable this mode, otherwise Supervisor will not be able to properly determine the status of the program.

For the sake of this article, we’ll assume we have a shell script we wish to keep persistently running that we have saved at /usr/local/bin/long.sh and looks like the following:

#!/bin/bash
while true
do 
	# Echo current date to stdout
	echo `date`
	# Echo 'error!' to stderr
	echo 'error!' >&2
	sleep 1
done

chmod +x /usr/local/bin/long.sh

In a practical sense, this script is clearly rather pointless, but it will allow us to cover the fundamentals of Supervisor configuration.

The program configuration files for Supervisor programs are found in the /etc/supervisor/conf.d directory, normally with one program per file and a .conf extension. A simple configuration for our script, saved at /etc/supervisor/conf.d/long_script.conf, would look like so:

command=/usr/local/bin/long.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/long.err.log
stdout_logfile=/var/log/long.out.log

We’ll look at the significance of each line and some of the tweaks that may be desirable for your program below:

command=/usr/local/bin/long.sh

The configuration begins by defining a program with the name ‘long_script’ and the full path to the program:

autostart=true
autorestart=true

The next two lines define the basic automatic behaviour of the script under certain conditions.

The autostart option tells Supervisor that this program should be started when the system boots. Setting this to false will require a manual start command following any system shutdown.

autorestart defines how Supervisor should manage the program in the event it exits and has three options:

• false’ tells Supervisor not to ever restart the program after it exits
• ‘true’ tells Supervisor to always restart the program after it exits
• ‘unexpected’ tells Supervisor to only restart the program if it exits with an unexpected error code (by default anything other than codes 0 or 2).

stderr_logfile=/var/log/long.err.log
stdout_logfile=/var/log/long.out.log

The final two lines define the locations of the two main log files for the program. As suggested by the option names, stdout and stderr will be directed to the stdout_logfile and stderr_logfile locations respectively. The specified directory specified must exist before we start the program, as Supervisor will not attempt to create any missing directories.

The configuration we have created here is a minimal reasonable template for a Supervisor program. lists many more optional configuration options that are available to fine tune how the program is executed.

Once our configuration file is created and saved, we can inform Supervisor of our new program through the supervisorctl command. First we tell Supervisor to look for any new or changed program configurations in the /etc/supervisor/conf.d directory with:

supervisorctl reread

Followed by telling it to enact any changes with:

supervisorctl update

Any time you make a change to any program configuration file, running the two previous commands will bring the changes into effect.

At this point our program should now be running and we can check this is the case by looking at the output log file:

$ tail /var/log/long.out.log
Sat Jul 20 22:21:22 UTC 2013
Sat Jul 20 22:21:23 UTC 2013
Sat Jul 20 22:21:24 UTC 2013
Sat Jul 20 22:21:25 UTC 2013
Sat Jul 20 22:21:26 UTC 2013
Sat Jul 20 22:21:27 UTC 2013
Sat Jul 20 22:21:28 UTC 2013
Sat Jul 20 22:21:29 UTC 2013
Sat Jul 20 22:21:30 UTC 2013
Sat Jul 20 22:21:31 UTC 2013

Success!

Subprocess Environment¶

Subprocesses will inherit the environment of the shell used to start
the supervisord program. Several environment variables
will be set by supervisord itself in the child’s
environment also, including (a flag
indicating the process is under supervisor control),
(the config-file-specified process
name for this process) and (the
config-file-specified process group name for the child process).

These environment variables may be overridden within the
section config option named (applies
to all subprocesses) or within the per- section
config option (applies only to the subprocess
specified within the section). These “environment”
settings are additive. In other words, each subprocess’ environment
will consist of:

No shell is executed by supervisord when it runs a
subprocess, so environment variables such as ,
, , , ,
etc. are not changed from their defaults or otherwise reassigned.
This is particularly important to note when you are running a program
from a supervisord run as root with a stanza in
the configuration. Unlike cron, supervisord
does not attempt to divine and override “fundamental” environment
variables like , , , and
when it performs a setuid to the user defined within
the program config option. If you need to set environment
variables for a particular program that might otherwise be set by a
shell invocation for a particular user, you must do it explicitly
within the program config option. An
example of setting these environment variables is as below.

1.0.2 or “Alpha 2” (Unreleased)

• supervisorctl and supervisord no longer need to run on the same machine
  due to the addition of internet socket support.
• supervisorctl and supervisord no longer share a common configuration
  file format.
• supervisorctl now uses a persistent connection to supervisord
  (as opposed to creating a fresh connection for each command).
• SRP (Secure Remote Password) authentication is now a supported form
  of access control for supervisord. In supervisorctl interactive mode,
  by default, users will be asked for credentials when attempting to
  talk to a supervisord that requires SRP authentication.
• supervisord has a new command-line option and configuration file
  option for specifying “noauth” mode, which signifies that it
  should not require authentication from clients.
• supervisorctl has a new command-line option and configuration
  option for specifying “noauth” mode, which signifies that it
  should never attempt to send authentication info to servers.
• supervisorctl has new commands: open: opens a connection to a new
  supervisord; close: closes the current connection.
• supervisorctl’s “logtail” command now retrieves log data from
  supervisord’s log file remotely (as opposed to reading it
  directly from a common filesystem). It also no longer emulates
  “tail -f”, it just returns <n> lines of the server’s log file.
• The supervisord/supervisorctl wire protocol now has protocol versioning
  and is documented in “protocol.txt”.
• “configfile” command-line override -C changed to -c
• top-level section name for supervisor schema changed to ‘supervisord’
  from ‘supervisor’
• Added ‘pidproxy’ shim program.

Known issues in alpha 2:

Nondaemonizing of Subprocesses¶

Programs meant to be run under supervisor should not daemonize
themselves. Instead, they should run in the foreground. They should
not detach from the terminal from which they are started.

The easiest way to tell if a program will run in the foreground is to
run the command that invokes the program from a shell prompt. If it
gives you control of the terminal back, but continues running, it’s
daemonizing itself and that will almost certainly be the wrong way to
run it under supervisor. You want to run a command that essentially
requires you to press Ctrl-C to get control of the terminal
back. If it gives you a shell prompt back after running it without
needing to press Ctrl-C, it’s not useful under supervisor. All
programs have options to be run in the foreground but there’s no
“standard way” to do it; you’ll need to read the documentation for
each program.

Below are configuration file examples that are known to start
common programs in “foreground” mode under Supervisor.

Two Zope 2.X instances and one ZEO server

command=/path/to/runzeo
priority=1


command=/path/to/instance/home/bin/runzope
priority=2
redirect_stderr=true


command=/path/to/another/instance/home/bin/runzope
priority=2
redirect_stderr=true

Postgres 8.X

command=/path/to/postmaster
; we use the "fast" shutdown signal SIGINT
stopsignal=INT
redirect_stderr=true

Supervisor的配置

3.1. supervisord.conf的配置

如果使用的命令安装，会生成默认配置和目录，如果没有则自行创建。

在的目录下创建和两个目录，用于存放管理进程的配置，用于存放管理进程的日志。

12

cd /etc/supervisord.dmkdir conf log

修改的部分，即载入目录下的所有配置。

12345

vi /etc/supervisord.conf...files = supervisord.d/conf/*.conf...

也可以修改supervisor应用日志的目录，默认日志路径为。

123456789

vi /etc/supervisord.conf...logfile=/var/log/supervisor/supervisord.log  ; (main log file;default $CWD/supervisord.log)logfile_maxbytes=50MB       ; (max main logfile bytes b4 rotation;default 50MB)logfile_backups=10          ; (num of main logfile rotation backups;default 10)loglevel=info               ; (log level;default info; others: debug,warn,trace)pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)...

3.2. 管理应用的配置

进入到目录，创建管理应用的配置，可以创建多个应用配置。

例如，创建配置。

123456789101112131415

directory = /usr/local/bin ; 程序的启动目录command = /usr/local/bin/confd -config-file /etc/confd/confd.toml ; 启动命令，与命令行启动的命令是一样的autostart = true     ; 在 supervisord 启动的时候也自动启动startsecs = 5        ; 启动 5 秒后没有异常退出，就当作已经正常启动了autorestart = true   ; 程序异常退出后自动重启startretries = 3     ; 启动失败自动重试次数，默认是 3user = root          ; 用哪个用户启动redirect_stderr = true  ; 把 stderr 重定向到 stdout，默认 falsestdout_logfile_maxbytes = 20MB  ; stdout 日志文件大小，默认 50MBstdout_logfile_backups = 20     ; stdout 日志文件备份数; stdout 日志文件，需要注意当指定目录不存在时无法正常启动，所以需要手动创建目录（supervisord 会自动创建日志文件）stdout_logfile = /etc/supervisord.d/log/confd.log  ;日志统一放在log目录下; 可以通过 environment 来添加需要的环境变量，一种常见的用法是修改 PYTHONPATH; environment=PYTHONPATH=$PYTHONPATH:/path/to/somewhere

Running supervisord¶

To start supervisord, run . The
resulting process will daemonize itself and detach from the terminal.
It keeps an operations log at by default.

You may start the supervisord executable in the foreground
by passing the flag on its command line. This is useful to
debug startup problems.

Warning

When supervisord starts up, it will search for its
configuration file in default locations including the current working
directory. If you are security-conscious you will probably want to
specify a “-c” argument after the supervisord command
specifying an absolute path to a configuration file to ensure that someone
doesn’t trick you into running supervisor from within a directory that
contains a rogue file. A warning is emitted when
supervisor is started as root without this argument.

To change the set of programs controlled by supervisord,
edit the file and or otherwise
restart the supervisord process. This file has several
example program definitions.

The supervisord command accepts a number of command-line
options. Each of these command line options overrides any equivalent
value in the configuration file.