控制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