某年某月某日，一个工程师跑来找我说：很多用户抱怨APP频繁闪退，他觉得server运行正常，找不出原因，请我帮忙
按照流程一路排查下去，发现nginx访问日志里面有大量的http 504 err code
tail -f /var/log/messages
同时出现大量的类似错误信息
nginx[1234]: segfault at 0000000000000008 rip 000000000043edf8 rsp 00007fff34a21fa0 error 4
出现segfault那只能用gdb了，这也是Linux做server的好处了，换成微软平台，无比的麻烦
解决问题分成4步：
-
配置系统生成coredump文件，很简单
ulimit -a
第一行就是关于core file的设置，默认是不生成coredump文件的，执行
ulimit -c 1024
即可，记得调试完成之后要用
ulimit -c 0
关闭，不然你的硬盘很快会被填满
-
gdb调试，需要debug版本的nginx才能定位到源代码，于是需要重新编译一份nginx
首先把现有的nginx bin目录和conf目录都备份
然后打印nginx的原始编译选项
/opt/nginx/sbin/nginx -V
在这个基础上加上 --with-debug,重新make一份即可
在${NGINX-SOURCE-DIR}$/objs 目录中找到编译好的nginx ，复制到你的nginx运行目录，切记不要make install ，因为这样会覆盖掉你的nginx.conf文件
-
重新运行nginx，等待core.xxx文件生成。一般是在当前目录下生成
-
用gdb加载 coredump 文件
gdb --core=core.xxx
gdb> where
很容易就找到了nginx segfault的原因：我们自己写的一个nginx modules里面，对某些参数没有做边界检查，但外部环境变化之后，访问空指针了
转自：
http://lutaf.com/140.htm
有一台阿里云上的服务器，上一任运维留下来的，里面装了
nginx
1.10.2 ，还开启了iptables。之前一直都是相安无事，内存占用率稳定达到85%-90%，cpu占用率偶尔达到50%，一般在10%以下。
突然一天，发现
nginx
设置跳转的域名无法连接，观察内存，cpu都没问题，连接数也正常，由于能力有限，因此也未进入查看内核方面的情况，只是做了些紧急措施，将重要的域...
最近在 Centos7 上搭建
nginx
作为 web 服务器使用，但是使用过程中，
nginx
总是莫名其妙的崩掉，使用命令 dmesg 检查错误信息如下：
[6655217.659132] Out of memory: Kill process 11494 (lsof) score 10 or sacrifice child
[6655217.659567] Killed process 11...
重新启动服务器，访问web服务发现无法浏览啦!登陆服务器之后进到
nginx
使用./
nginx
-s reload重新读取配置文件，发现报
nginx
: [error] open() "/usr/local/
nginx
/logs/
nginx
.pid" failed (2: No such file or directory)错误，进到logs文件发现的确没有
nginx
.pid文件[root@local...
通过 sudo cat /var/log/messages |grep segfault 或者 sudo dmesg|grep segfault 获得
这种信息一般都是由内存访问越界造成的，不管是用户态程序还是内核态程序访问越界都会出core, 并在系统日志里面输出一条这样的信息。这条信息的前面分别是访问越界的程序名，进程ID号，访问越界的地址以及当时进程堆栈地址等信息，比较有用的信息是
Linux下一般情况程序出现段错误异常
崩溃
时，并不会产生core文件，此时可借助/var/log/messages中打印的错误信息进行排查。如下错误信息：
segfault at 7f30beffe000 ip 00007f30c6eebda9 sp 00007f30a7ffc4a0 error 4 in libc-2.17.so[7f30c6e56000+1c3000]
其中，异常在libc-2.17.so库中，00007f30beffe000为出错地址，7f30c6eebda9为指令地址，00007
在调试
Nginx
功能的时候，出现如下问题：
2017/02/27 16:23:50 [notice] 13604#0: signal 17 (SIGCHLD) received
2017/02/27 16:23:50 [alert] 13604#0: worker process 1360...
