打印日志log引发的sig 13惨案

不用多说太多，大家很容易了解nohup函数和log重定向知识。

但谈到一个android c 应用程序后台运行一段时间后，就被init进程sig 13 kill就很有趣了。

事情是这样，为了解一个bug，用c写了一个应用程序，持续后台运行监控系统状况。

但执行一段时间后，进程log就不再打印。

查询log看到一个有趣的讯息：

 KERNEL  : [  429.182108] (CPU:3-pid:1:init) [18:37:20.862927918] init: Untracked pid 14535 received signal 13

PID 14535就是后台运行的程序，首先可排除是被lmk杀掉。

但有效讯息只有一个sig 13 ，通过kill -l可知sig 13对应  PIPE Broken pipe。

但我的程序根本没用到pipe和socket，难道是使用的系统函数用到了socket或pipe？

这里直接给出结论，是因为tool中使用printf打印了log

执行tool的方式为

adb shell "/data/_monitor &"

因为adb进程后台不会被kill，所以命令执行后可通过adb binding到后台进程并重定向log到当前console。即使拔掉usb，程序可可继续执行。

但usb拔掉后，console进程被断链，log试图通过pipe输出到console，但console被断链，printf找不到对应的输出端口，init发现后就会通过sig 13杀掉进程。 

解决办法有两种：

1：将log重定向到文件，避免log buffer塞满后，触发sig pipe。

adb shell "/data/_monitor >file/log.txt 2>&1 &"

2: 通过ALOGD之类的logcat log打印。

当然，也可以使用如下命令来执行（可能下面的更好？）

adb shell "nohup /data/_monitor >file/log.txt 2>&1 &"

顺带提出一个有趣的现象思考：

大家都知道在服务器上想后台执行一个程序，可用nohup + & 搭配执行。

也知道nohup做的事情其实很少，但执行某些程序可能看到如下错误

 $ nohup: //nohup.out: Read-only file system

结合我的实验基本可断定，nohup命令为了避免sig13杀掉后台执行的进程，默认会重定向log，如果用户不指定重定向地址，则会使用默认路径。但默认路径在安卓系统上恰好readonly。

解决办法很简单，使用

 $ nohup cmd 1 > logpath/log.txt   2>&1  & 

将log重定向，就可以解决报错并正常执行。