是oom-killer还是接收了SIGHUP信号 导致进程挂死

最近在定位用户态的一个进程kerneld进程意外挂死的情况，但无法进行复现，只从代码的角度分析挂死原因，

感觉应该是意外接收了某个信号，处理信号时exit了，，要么就是normal内存块中剩余内存大于low小于Middle，

造成内核释放用户态占用过多的内存的进程，，但资料上说，当剩余内存小于low时就触发了oom-killer，，

然后对对用户态进程进行大规模杀害，直到剩余内存大于high。

p.s kerneld 进程在烧写镜像时会占用大量的内存。

此外该进程的SIGHUP信号处理函数中有exit 0， 所以学习一下后台进程能收到和处理怎样的信号。

注意：以下内容为转载的，原文链接为，http://blog.csdn.net/hbhhww/article/details/6800772

此处仅做记录学习。

当我们需要在远程测试环境中运行诸如压力测试等需要后台运行的程序，但是当你关闭了远程登录的窗体时，

却意外的也关闭了你的后台程序。这个问题的原因是：后台执行的进程，其父进程还是当前终端shell的进程，

而一旦父进程退出，则会发送hangup信号给所有子进程，子进程收到hangup以后也会退出。

你可以使用下面的命令解决这个问题nohup ./test.sh &

SIGUP 

unix中进程组织结构为 session 包含一个前台进程组及一个或多个后台进程组，一个进程组包含多个进程。

一个session可能会有一个session首进程，而一个session首进程可能会有一个控制终端。

一个进程组可能会有一个进程组首进程。进程组首进程的进程ID与该进程组ID相等。

这儿是可能会有，在一定情况之下是没有的。

与终端交互的进程是前台进程，否则便是后台进程

SIGHUP会在以下3种情况下被发送给相应的进程：

1、终端关闭时，该信号被发送到session首进程以及作为job提交的进程（即用 & 符号提交的进程）

2、session首进程退出时，该信号被发送到该session中的前台进程组中的每一个进程

3、若夫进程退出导致进程组成为孤儿进程组，且该进程组中有进程处于停止状态（收到SIGSTOP或SIGTSTP信号），

该信号会被发送到该进程组中的每一个进程。

系统对SIGHUP信号的默认处理是终止收到该信号的进程。所以若程序中没有捕捉该信号，当收到该信号时，进程就会退出