浙江省高等学校教师教育理论培训

微信搜索“毛凌志岗前心得”小程序

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

http://supervisord.org/api.html xmprpc inovke api document

byteflow/django supervisord nginx = WIN

http://just-another.net/byteflowdjango-supervisord-nginx-win

 


urllib2 - The Missing Manual

HOWTO Fetch Internet Resources with Python

http://www.voidspace.org.uk/python/articles/urllib2.shtml#handling-exceptions <---很牛的py站

 

 

  #1  
Old 11-10-2009, 03:40 PM
I Got Nodes
 
Join Date: Aug 2009
Posts: 45
njmattes is on a distinguished road

Default How-To: Spawn PHP with supervisord (for NGINX on Debian)

 



Just to muddy the waters for people trying to decide between spawn-cgi and php-fpm, there's a third way to spawn php-cgi for NGINX. It's a process manager called supervisord, which will start any number of processes you want (you can use it for ssh, mysql, etc.) -- monitor them while they run, and restart them if they fail. I was previously using php-fpm, so that's reflected in some of the code below.

It can be slightly tricky, because it starts processes as sub-processes of itself. So any process you start with supervisord can't be running in daemon mode.

It's written in python and super easy to install.

Code:
aptitude install python-setuptools
easy_install supervisor

You need to make several modifications to your config file, which is located at /etc/supervisord.conf.

If you want to check the status of the supervisord processes through its wonderful web interface (make sure the port is open in iptables):

Code:
[supervisorctl]
serverurl=http://your.ip.add.ress:port
username=somename
password=somepass

Each process you want to start needs an entry in the config file. We'll start with PHP:

Code:
[fcgi-program:php-cgi]
command=/path/to/php-cgi
;socket=unix:///tmp/%program_name)s.sock
socket=tcp://127.0.0.1:9000
process_name=%(program_name)s_%(process_num)02d
user=www-data
numprocs=2
priority=999
autostart=true
autorestart=unexpected
startsecs=1
startretries=3
exitcodes=0,2
stopsignal=QUIT
stopwaitsecs=10

Socket needs to match the socket that NGINX is looking for. 127.0.0.1:9000 is pretty standard, but look at your nginx.conf file. The commented line is there if you want to listen on a unix socket instead.

I've been using supervisord to start all of the processes that I want monitored, so:

Code:
[program:sshd]
command=/path/to/sshd -D -e
process_name=%(program_name)s
autostart=true
autorestart=true

[program:postgres]
command=/path/to/postmaster -D "/path/to/databases"
process_name=%(program_name)s
stopsignal=INT
user=postgres
autostart=true
autorestart=true

[program:nginx]
command=/path/to/nginx
process_name=%(program_name)s
autostart=true
autorestart=true

For each program you start, you probably want to specify a log file, max size of the file, and amount of backups to rotate:

Code:
[program:someprogram]
redirect_stderr=true
stdout_logfile=/path/to/someprogram.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10

Before you start supervisord, open your nginx.conf file and add this to the top, so it doesn't try to start in daemon mode:

Code:
daemon off;

Here's a simple init.d startup script for supervisord (put it her: /etc/init,d/supervisord):

Code:
#!/bin/sh
### BEGIN INIT INFO
# Provides:          supervisor
# Default-Start:     2 3 4 5
# Default-Stop:      S 0 1 6
# Short-Description: Starts/stops the supervisor daemon
# Description:       This starts and stops the supervisor dameon
#                    which is used to run and monitor arbitrary programs as
#                    services, e.g. application servers etc.
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="supervisor daemon"
NAME="supervisor"
DAEMON="/usr/bin/${NAME}d"
SUPERVISORCTL="/usr/bin/${NAME}ctl"
PIDFILE="/var/run/${NAME}d.pid"
SCRIPTNAME="/etc/init.d/$NAME"
CONFFILE="/etc/${NAME}d.conf"

test -x "$DAEMON" || exit 0
test -r "$CONFFILE" || exit 0

if [ -r "/etc/default/$NAME" ]; then
    . "/etc/default/$NAME"
fi

set -e

d_start() {
    start-stop-daemon --start --quiet --pidfile "$PIDFILE" \
        --exec "$DAEMON" \
        || echo -n " already running"
}

d_stop() {
    $SUPERVISORCTL shutdown
}

d_reload() {
    $SUPERVISORCTL reload
}

case "$1" in
  start)
    echo -n "Starting $DESC: $NAME"
    d_start
    echo "."
    ;;
  stop)
    echo -n "Stopping $DESC: $NAME"
    d_stop
    echo "."
    ;;
  reload|force-reload)
    echo -n "Reloading $DESC configuration..."
    d_reload
    echo "done."
  ;;
  restart)
    echo -n "Restarting $DESC: $NAME"
    d_stop
    sleep 1
    d_start
    echo "."
    ;;
  *)
    echo "Usage: "$SCRIPTNAME" {start|stop|restart|force-reload}" >&2
    exit 3
    ;;
esac

exit 0

Then:

Code:
chmod +x /etc/init.d/supervisord
update-rc.d supervisord defaults

If you're feeling randy, go ahead and remove the programs that supervisor will be starting from rc.d so they don't start twice when you reboot:

Code:
update-rc.d -f nginx remove
update-rc.d -f postgres remove
update-rc.d -f php-fpm remove
update-rc.d -f ssh remove

Then reboot, your VPS and eveything should be running. If you'd rather test it first, don't add ssh to your supervisord.conf file (I suppose you could get booted from your shell if anything goes haywire). Then:

Code:
/etc/init.d/nginx stop
/etc/init.d/postgres stop
/etc/init.d/php-fpm stop
/etc/init.d/supervisord start

If you go to the fancy web interface (set up above in the [supervisorctl] options), you should see what's running (hopefully everything) and what's not (hopefully nothing). Or you can run top or whatever command line utility you desire.

Now here's the scary part. Because every process is a sub-process of supervisord, if supervisord were to fail, it stands to reason that every process that it started will fail as well. So, and this might be overkill, I run monit as well. I use monit to watch supervisor. In monitrc:

Code:
check process supervisord
	with pidfile /path/to/supervisord.pid
	start program "/etc/init.d/supervisord start"
	stop program "/etc/init.d/supervisord stop"
	if failed unixsocket /tmp/supervisor.sock then restart
	if 5 restarts within 5 cycles then timeout

If monit goes down, and then supervisor goes down, then I guess I'm screwed. But I don't anticipate that happening. If you're prone to paranoia, you could daisy-chain runit, god, nagios, and who knows what else.

The whole process may seem a bit convoluted, but once you get it running it's wonderful. At least I think so.


Last edited by njmattes; 11-10-2009 at 04:14 PM.

Supervisord to manage your daemons

http://www.ivy.fr/blog/index.php/2009/12/21/106-supervisord-to-manage-your-daemons good ,deploy redis on supervisord

 

 

http://gist.github.com/593962 


an init.d script for supervisord

 

nginx / ngx_supervisord (project fully funded by megiteam.pl)
Module providing nginx with API to communicate with supervisordand manage (start/stop) backends on-demand.

As a "side effect", it also provides a way for dynamically taking backend servers out of rotation.

View:
README file,
CHANGES file,
APIv2 specification.

Download:
ngx_supervisord-1.4
(SHA1: e61f09244d30f3652f7276088470be2031b3666e)

GitHub repository:
http://github.com/FRiCKLE/ngx_supervisord/

Example configuration:

upstream backend {
	server 127.0.0.1:8000;
	server 127.0.0.1:8001;
	supervisord 127.0.0.1:9001 admin:super;
	fair;
}

server {
	location / {
		proxy_pass http://backend;
	}
}

 

 

 


superlance 0.5

superlance plugins for supervisord

Downloads ↓

superlance plugins for supervisor
=================================

Superlance is a package of plugin utilities for monitoring and
controlling processes that run under `supervisor
`_.

Currently, it provides two scripts:

``httpok`` -- This script can be used as a supervisor event listener
(subscribed to TICK events) which will restart a "hung" HTTP server
process, which is defined as a process in the RUNNING state which does
not respond in an appropriate or timely manner to an HTTP GET request.

``crashmail`` -- This script will email a user when a process enters
the EXITED state unexpectedly.

``memmon`` -- See the description below.

Memmon Overview
---------------

memmon is a supervisor "event listener" which may be subscribed to a
concrete TICK_x event. When memmon receives a TICK_x event (TICK_60 is
recommended, indicating activity every 60 seconds), memmon checks that a
configurable list of programs (or all programs running under supervisor) are
not exceeding a configurable about of memory (resident segment size, or RSS).
If one or more of these processes is consuming more than the amount of memory
that memmon believes it should, memmon will restart the process. memmon can be
configured to send an email notification when it restarts a process.

memmon is known to work on Linux and Mac OS X, but has not been tested on
other operating systems (it relies on ps output and command-line switches).

memmon is incapable of monitoring the process status of processes which are
not supervisord child processes.

Memmon Command
--------------

memmon is a "console script" installed when you install supervisor. Although
memmon is an executable program, it isn't useful as a general-purpose script:
it must be run as a supervisor event listener to do anything useful. memmon
accepts the following options:
综述性文章

 

 

 

posted on 2010-09-24 00:42  lexus  阅读(582)  评论(0编辑  收藏  举报