worker process 245421 exited on signal 11

问题引出：这几天在重现一些问题时，用到nginx时，在部署好nginx后去curl时出现了no response data的问题，用浏览器抓包分析时也发现，并没有任何返回的数据，这让我觉得很奇怪，任何http状态码都没有返回，不管怎么调整nginx的配置，结果还是这样。

1、查看了nginx的错误日志，发现了worker process 245421 exited on signal 11的报错：

2、查看了一些nginx的相关知识，摘录了http://tengine.taobao.org/book/chapter_02.html原话：nginx采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。为了验证nginx的一个work挂掉后，master进程会很快启动新的work进程，做了如下验证：

通过上面我们可以看到，当我curl的时候，nginx错误日志报出master（245397）的245399的work进程exited，然后重新查看nginx进程发现，原来的245399work进程不在了，多出来一个245491的work进程。

从这里大概可以看出nginx没有返回数据的原因是，nginx的work进程在处理该request的时候出现了异常导致该work进程直接挂了，没有返回任何data。上面也说到，work进程挂了是因为代码有bug的，这里基本可以否定这点，因为我在inde.html上只是写了简单的几个字符。

3、原因探索：这里发现dmesy日志中并没有报出任何错，参考了网上的资料，都能在dmesg日志中找到相关的错误日志，对于这里为何会没dmesg日志产生，暂先不做深究。

继续Google相关的错误，在一篇名为Nginx — How to Fix Reponse Status 0 (Worker Process Exited)  https://futurestud.io/tutorials/nginx-solve-reponse-status-0-worker-process-exited的文章中了解到，这种情况的http code应该是0= =

这篇文章的报错如下：仔细看下，报错类似，但最后多了一个core dumped。

苦于没有解决方案，尝试了一下这篇文章的解决方案，并且记录一下nginx的work共享session信息的方法= =  实践证明，这个问题好像并不是由于nginx work的ssl信息不共享导致的。

4、问题解决：只要换一下nginx的版本就不会出现这个问题了，我将nginx的版本换为1.8.1，问题就解决了。但出于想了解出现这个报错的根本原因，在Google找了好久资料，了解到有很多nginx的版本（1.10,1.11.1等）都有出现这个报错的情况。求科普真相。有空也将继续学习探讨。