一次冗长繁琐的排错经历

Posted slgkaifa

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次冗长繁琐的排错经历相关的知识,希望对你有一定的参考价值。

一次冗长繁琐的排错经历

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

因项目关系,须要在測试环境中开启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命令能够查看内核的一些错误信息。果不其然:

Libcrypto.so是openssl的动态链接库,这里假设segfault了,导致process exit也就在意料之中了。

如今基本清楚了:openssl的Libcrypto.so导致了segfault(也许可能还有其它原因?)。从而引起了进程的异常退出,这与nginx的signal 11进程退出的表现也是基本一致的。本来事情能够非常easy的,可是!在这之后,犯了一个及其低级的错误!在检查完openssl, openssl-devel是最新的版本号之后。想当然的以为是之前openssl的安装出现了错误,于是果断卸掉openssl,又一次安装,而这也导致之后走了非常长时间的弯路。又一次安装openssl之后,重新启动nginx时,出现例如以下错误:

error while loading shared libraries: libcrypto.so.4: cannot open share object ......

又是libcrypto.so的问题!查看nginx引用动态库的映射关系:

ldd $(which /xxx/xxx/webserver/sbin/nginx)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000318ea00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000318b200000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x000000317ac00000)
libcrypto.so.4 => 没有找到

根本没有libcrypto.so.4,应该是之前卸载openssl时被干掉了。

http://rpm.pbone.net搜索libcrypto.so.4,发现带该动态的库openssl版本号是openssl097a-0.9.7,最新的openssl貌似是不带的。隐约中记得之前的开发机上的openssl没有升级过。果断登上。果然在/lib64/发现了libcrypto.so.4。scp过来之后,再次运行ldd命令。发现nginx已经能够找到libcrypto.so.4了:

ldd $(which /xxx/xxx/webserver/sbin/nginx)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000318ea00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000318b200000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x000000317ac00000)
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003198700000)

再次重新启动nginx,没有报错了。

再次訪问https,熟悉的界面最终出来了:

附录:几个用到的命令

1.查看OPenSSL的版本号:                                                     

    Openssl version

2.查看内核的消息:

    dmesg

3. rpm包管理工具:

    rpm –qa openssl*

4. yum包管理工具

    yum install openssl openssl-devel

5. 定位包:

    whereis libcrypto.so

    locate libcrypto.so

6. 查看nginx依赖的动态库:

    ldd $(which /xxx/sbin/nginx)

7. 假设有coredump文件,建议用gdb调试。

8. 假设你的libcrypto.so.4不是这样的格式。能够通过建立软连接的形式解决:

    ln –s libcrypto.so.0.9.7a libcrypto.so.4

參考文档:

  1. http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
  2. http://trac.nginx.org/nginx/ticket/618
  3. http://rpm.pbone.net/index.php3?stat=3&limit=4&srodzaj=1&dl=40&search=libcrypto.so.4&field[]=1&field[]=2
  4. http://forum.directadmin.com/showthread.php?t=21131
  5. http://blog.csdn.net/lsbhjshyn/article/details/38734261
  6. http://bbs.chinaunix.net/thread-2117172-1-1.html
  7. http://94j69.blog.51cto.com/542780/1127224
  8. http://lazycat.is-programmer.com/posts/31925.html
  9. http://lutaf.com/140.htm

以上是关于一次冗长繁琐的排错经历的主要内容,如果未能解决你的问题,请参考以下文章

记一次让人的喷血的排错经历

.NetCore中IdentityServer使用nginx-proxy的一次排错经历

一次帮DBA排错的经历分享!

问题解决:一次进 “源码” 排错的经历,学到了

一次OpenStack虚拟机热迁移的排错经历

问题解决:一次进 “源码” 排错的经历,学到了