控制uwsgi 的信号量
最近在用nginx+uwsgi+djano搭建一个网站，当.py文件修改后，如果不重启uwsgi，修改无法应用。
查了下uwsgi的相关文档 ，找到几个解决方案。顺便翻译下以备查看
启动服务
Starting an uWSGI server is the role of the system administrator, like starting the Web server. It should not be the role of the Web server to start the uWSGI server – though you can also do that if it fits your architecture.
同启动web服务器一样，启动uWSGI服务器需要系统管理员的角色。最好不要用启动Web Server的角色启动uWSGI server-如果那样做适合你的架构的话也可以做。
How to best start uWSGI services as boot depends on the operating system you use.
On modern systems the following should hold true. On “classic” operating systems you can use init.d/rc.d scripts, or tools such as Supervisor, Daemontools or inetd/xinetd.
如何最好得启动uWSGI服务依赖于你所使用的操作系统。
以下的方法适用于现代的操作系统。在“classic"操作系统中你可以使用init.d/rc.d脚本，或者使用Supervisor, Daemontools等工具，或者inetd/xinetd.
| System | Method |
|---|---|
| Ubuntu | Running uWSGI via Upstart (the official uwsgi package, available since Ubuntu 12.04 provides an init.d based solution. Read the README.) |
| Debian | Running uWSGI via Upstart |
| Fedora | SystemD |
| OSX | launchd |
| Solaris | SMF |
Signals for controlling uWSGI
You can instruct uWSGI to write the master process PID to a file with the pidfile option.
The uWSGI server responds to the following signals.
您可以使用 pidfile选项指示uWSGI将master进程的PID写入到一个文件中。
uWSGI服务器响应以下的信号量。
| Signal | Description | Convenience command |
|---|---|---|
| SIGHUP | gracefully reload all the workers and the master process | –reload |
| SIGTERM | brutally reload all the workers and the master process | |
| SIGINT | immediately kill the entire uWSGI stack | –stop |
| SIGQUIT | immediately kill the entire uWSGI stack | |
| SIGUSR1 | print statistics | |
| SIGUSR2 | print worker status or wakeup the spooler | |
| SIGURG | restore a snapshot | |
| SIGTSTP | pause/suspend/resume an instance | |
| SIGWINCH | wakeup a worker blocked in a syscall (internal use) |
Reloading the server
When running with the master process mode, the uWSGI server can be gracefully restarted without closing the main sockets.
This functionality allows you patch/upgrade the uWSGI server without closing the connection with the web server and losing a single request.
When you send the SIGHUP to the master process it will try to gracefully stop all the workers, waiting for the completion of any currently running requests.
Then it closes all the eventually opened file descriptor not related to uWSGI.
Lastly, it binary patches (using execve()) the uWSGI process image with a new one, inheriting all of the previous file descriptors.
The server will know that it is a reloaded instance and will skip all the sockets initialization, reusing the previous ones.
当运行在master处理模式时，uWSGI服务器可以优雅地重启，且不需要关闭主sockets.
这个功能允许您在不关闭链接且不丢失任何一个请求的情况下修补/升级uWSGI服务器。当您发出一个sighup到master进程的时候，它将会优雅地停止所有的工作进程，等待当前结束当前运行中的请求。然后它关闭所有最终打开的与uWSGI无关的文件描述符。最后，它通过二进制修复（使用 execve()）打开一个新的uWSGI进程镜像，继承所有之前的文件描述符。服务器知道它已经重新加载了一个实例并跳过所有的sockets的初始化，复用之前的sockets。
Note
Sending the SIGTERM signal will obtain the same result reload-wise but will not wait for the completion of running requests.
发送信号量sigterm可以达到同样的reload效果，区别在于它不会等待正在运行的请求完成。
There are several ways to make uWSGI gracefully restart.
有几种使得uWSGI优雅重启的方式：
# using kill to send the signal
kill -HUP `cat /tmp/project-master.pid`
# or the convenience option --reload
uwsgi --reload /tmp/project-master.pid
# or if uwsgi was started with touch-reload=/tmp/somefile
touch /tmp/somefile
Or from your application, in Python:
uwsgi.reload()
Or in Ruby
UWSGI.reload
Stopping the server
If you have the uWSGI process running in the foreground for some reason, you can just hit CTRL+C to kill it off.
When dealing with background processes, you’ll need to use the master pidfile again. The SIGINT signal will kill uWSGI.
如果在一些情况下您的uWSGI进程在前台运行，您可以使用CTRL+C杀掉它。
如果是后台运行的话，您需要使用pidfile，信号量sigint将杀掉uWSGI。
kill -INT `cat /tmp/project-master.pid`
# or for convenience...
uwsgi --stop /tmp/project-master.pid
