记一个 linux 程序无提示退出问题

1.问题描述

程序有多个线程，主线程启动一个线程拉取远端的视频流，在拉取视频流的回调函数里对获取的数据进行处理。主线程启动拉流线程之后就在 while(1) 中进入睡眠状态，剩下拉流线程拉取数据并进行处理。

目前遇到的问题是：程序运行一段时间没有任何提示就退出了，按照预期，没有人为干预结束这个程序，应该一直运行下去。这个问题是必现的，只是有时候程序可以运行一天有时候半个小时，之后就会出现这个现象。
从应用程序的日志看不出任何异常，日志就是戛然而止。

2.猜想与验证

比较明显的事实是，程序被系统停止了，但是为什么会被停止，需要去寻找可能的原因。

（1） 根据 top 命令观察程序运行时的资源占用情况
从 top 命令看到程序的资源占用情况非常稳定，运行几个小时内存和 CPU 占用几乎不变，在一个很小的区间内窄幅波动。
通过这种方式看不出任何异常。

（2） 查看系统日志
在某些情况下，程序被系统 kill 后，在系统日志中会记录一些信息，所以可以试着通过系统日志寻找异常。下面的代码摘抄自：Linux下应用进程消失原因分析

dmesg | egrep -i -B100 'killed process'

## 或:
egrep -i 'killed process' /var/log/messages
egrep -i -r 'killed process' /var/log

## 或:
journalctl -xb | egrep -i 'killed process'

查看系统日志同时还参考了：CentOS7 - 快速查看系统日志
遗憾的是，通过这种日志分析，没有发现任何异常。

(3) 程序收到系统的停止信号
在遇到这个问题之前，对程序可能收到的信号了解很少，只知道几个非常常用的，经过检索才发现有这么多信号会导致程序退出，并且只有少部分能够产生 core dump 文件。
在收到停止信号这个方面，有两种可能，一是收到了可以产生转储文件的停止信号，但是没有产生转储文件；二是收到的就是不产生转储文件的信号。

产生转储文件的信号
针对收到可以产生转储文件的信号，但是没有产生转储文件的情况，经过检索发现设置如下命令可以让程序在收到停止信号时产生转储文件。设置让系统在收到可以生成 core dump 文件的信号时生成转储文件，有两种方式，一种只针对当前终端有效，一种是永久性的。

当前终端有效
在命令行终端输入以下命令：

ulimit -c 
ulimit -c unlimited

永久有效
在命令行以 root 权限打开 /etc/profile 文件，在文件末尾加入一句： ulimit -c unlimited。

# sudo vim /etc/profile
# source /etc/profile

需要注意的是，如果只是在命令行窗口取消对生成转储文件的限制，仅对当前窗口有效，新开的窗口还是受到限制。按照修改 /etc/profile 文件的方式，可以对所有窗口生效，并且重启后仍然有效。

在设置好之后，写了一个简单的程序验证是否可以产生转储文件，确实经过设置后在程序崩溃时可以产生转储文件。

继续运行需要分析的程序，遗憾的是程序退出后没有留下任何痕迹，也就是没有留下转储文件。

参考：linux 下如何打开core dump文件开关

不产生转储文件的信号
按照目前分析的结果来看，程序无提示退出极大可能是因为收到不产生转储文件的停止信号，如何捕获让程序退出的信号呢？

网上很多的方案是在程序中设置捕获这些信号的处理方法，然而能够让程序不产生转储文件的停止信号那么多，如果针对每一个信号都写处理方法，真的有点麻烦，这是万不得已才去验证的方法。
在请教同事的时候，他提出了可以通过 gdb 运行程序，这样就可以在程序退出的时候打印收到的信号。经过一段时间的运行，程序果然如预期的退出，在 gdb 环境中打印出的信息如下：

根据后文给出的参考资料，程序果然是收到了不产生转储文件的停止信号。

虽然对于为什么程序会收到这个信号还不清楚，但是目前知道程序退出是因为这个信号了，也算是往前进了一步。

之后可以打印出当前状况下的所有堆栈信息，并保存为文件，供进一步分析，或方便转交给其他人分析。设置 gdb 将堆栈信息输出到文件的命令为：

(gdb) set logging file /tmp/test.txt
(gdb) set logging on
(gdb) thread apply all bt

参考：
linux下网络程序遭遇SIGPIPE信号进程退出的原因及规避方法
linux下多线程由于SIGPIPE退出进程的分析
Linux信号(signal)机制
Linux进程被信号杀死后退出状态码(exit code)的分析
在gdb中如何将所有线程的堆栈输出到文件中去

3. 小结

回过头来看，这个问题定位其实挺简单的，只是我对 linux 调试不熟悉，导致绕了很大一个圈子才初步找到问题所在，以后还是要积极面对问题，在解决问题的过程中收获成长。