一次冗长繁琐的排错经历

一次冗长繁琐的排错经历

白白忙活了一个下午+半个早饭的时间。感慨一下, 解决问题的思路很重要啊，否者就会像无头苍蝇一样，到处乱撞。

因项目关系，需要在测试环境中开启https，悲剧的是，在经过了机器迁移之后，之前可用的https连接失败了：

 

而Nginx中也只有寥寥几行的错误日志：

 

这里首先说明一下，Nginx对HTTPs的支持是通过Module ngx_http_ssl_module来实现的。而这需要保证几点：

1. 编译nginx的时候启动了ngx_http_ssl_module模块。(nginx –V查看编译选项 包含--with-http_ssl_module)
2. 在配置文件中开启了SSl并且配置正确（详情查看：http://nginx.org/en/docs/http/ngx_http_ssl_module.html）。
3. 系统安装了openssl（yum list install / rpm –qa, openssl version）

在确认以上三点无误后，再次将目标锁定到nginx的错误日志上。需要注意的是alert的worker process xxx exit on signal 11，也就是说，nginx的worker进程由于"某种原因"退出了，对于退出的原因，却没有丝毫的线索。而"没有线索"恰恰是调试的最大障碍，就好比是你只告诉119起火了，却没有告知事故地址，你让消防队员如何救火？木有core dump，错误日志又一头雾水，各种度娘、谷哥无果…..但，战斗还是要继续，烽火不会因为你的放弃而停止燃烧。

突然想起来，linux提供了dmesg命令可以查看内核的一些错误信息，果不其然：