nginx在運行過程中是否穩定，是否有異常退出過？這里總結幾項平時會用到的小技巧。
1. 在error.log中查看是否有signal項，如果有，看看signal是多少。
比如，這是一個異常退出的情況：
$grep signal error.log 2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11
如果在進程退出后，有coredump文件產生，則會打出如下日志：
$grep signal error.log 2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11 (core dumped)
2. 簡單方式，看進程號是否連續
一般來說，在worker進程啟動時，其進程號都是連續的（至少相差不是很遠），如果有進程退出，其進程號就不一定連續。
$ps aux | grep nginx lizi 7223 0.0 0.0 74844 2024 ? Ss 13:32 0:00 nginx: master process ./nginx lizi 7292 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7293 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7294 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7295 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7296 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7297 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7298 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7299 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7300 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process lizi 7301 0.0 0.0 78856 5452 ? S 13:33 0:00 nginx: worker process
可以看到，10個worker進程，基本從7292到7301，進程號連續。
如下：
$ps aux | grep nginx nobody 9492 16659 26 09:18 ? 01:10:41 nginx: worker process root 16659 1 0 Dec24 ? 00:00:00 nginx: master process ./nginx nobody 16663 16659 11 Dec24 ? 02:41:38 nginx: worker process nobody 19344 16659 24 10:18 ? 00:50:54 nginx: worker process nobody 25447 16659 28 07:41 ? 01:43:56 nginx: worker process
進程號已不再連續，說明nginx可能有工作進程異常退出。
3. 查看dmesg系統消息。
在man手冊里面是這么描述dmesg的：
DESCRIPTION dmesg is used to examine or control the kernel ring buffer.
查看dmesg是檢測系統運行狀態的常用手段，通常可以幫我們排查很多問題。當然，如果有進程異常退出，dmesg也可以看到。
$dmesg nginx[24721]: segfault at 0000000000000001 rip 0000000000000001 rsp 00007ffff58d8180 error 14 nginx[1729]: segfault at 0000000000000190 rip 00000000004c2d27 rsp 00007ffff58d8340 error 4 nginx[22002]: segfault at ffffffffffffffff rip 000000001c959744 rsp 00007fff43caac18 error 6
rip表示程序退出時的ip寄存器內容，當沒有core文件可用時，可根據此值以及反匯編來查找程序core的位置。
4. 打開coredump文件。
一般我們在程序啟動前，通過ulimit -c ulimited來設置core文件的大小，也可以修改/etc/security/limits.conf文件，添加如下信息：
admin soft core 1000000 admin hard core 1000000
也可以直接修改nginx的配置文件，添加如下配置項：
worker_rlimit_core 10000m;
而此時，在limit系統中，默認coredump文件會寫在啟動nginx時的目錄，如果nginx在啟動時worker進程的用戶沒有權限寫到這個目錄，進程在異常退出時，就無法產生coredump文件。由於nginx啟動后，或者是由別人啟動，我們無法知道nginx在啟動時的目錄，也就無法知道core文件的目錄。我曾經碰到過這樣的問題，通過日志查看，是coredump出來了，但卻找不到coredump的文件。
這里有一個小技巧，查看/proc/pid/cwd可以看到進程的工作目錄，而core文件會產生在工作目錄。
nginx可以配置工作目錄來改變默認的工作目錄，於是，我們需要配置working_directory為目的工作目錄，我們的core文件也會產生在這個目錄。
working_directory /path/to/core;
working_directory與編譯時指定的--prefix=/path不同，后者表示在配置文件中所用的相對路徑所生產的絕對路徑。所以，working_directory不會影響到配置的引用路徑，而僅僅是為了改變core文件的路徑，當然nginx必須有寫這個目錄的權限，否則無法core出來。
所以，這里，我推薦的做法是，配置worker_rlimit_core與working_directory這兩個指令，這樣，就不需要修改操作系統的參數就可以正常core出來了。