谁在Ubuntu服务器上神秘地发送SIGKILL到我的进程

概述谁在Ubuntu服务器上神秘地发送SIGKILL到我的进程

10月25日更新：

现在我知道是什么原因造成了这个问题。

1）subprocess自杀，这就是为什么strace / perf / auditctl无法追踪它。

2）创build进程的JNI调用是从Java线程触发的。 当线程最终死亡时，它也正在破坏它创build的过程。

使用-fPIC编译的程序在GDB中跨越线程局部variables时崩溃

找不到glib.h和gtk.h

“集群”软件与MPI有什么关系？

用户可能无法在linux系统上打开共享内存对象的原因

编程读取文件，并用pipe道发送给父进程

3）在我的代码fork和execve（）一个subprocess，我有代码来监视父进程的死亡和杀死我的subprocess使用以下行：prctl（PR_SET_PDEATHSIG，SIGKILL）; 我的错，在b / c之前，我没有特别留意这个标志，它被认为是我的其他项目的最佳实践，其中subprocess从主线程派生出来。

4）如果我注释掉这个问题，问题就没有了。 最初的目的是在父进程结束后终止subprocess。 即使没有这个标志，它仍然是正确的行为。 看起来像Ubuntu的框默认行为。

5）最后发现它是一个内核BUG，在内核版本3.4.0中修复，我的AWS的ubuntu盒子是内核版本3.13.0-29-generic。

有几个有用的链接来解决这个问题：

a） http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

b） 在父线程退出时调用prctl（PR_SET_PDEATHSIG，SIGNAL），而不是父进程退出 。

c） https://BUGzilla.kernel.org/show_BUG.cgi?ID=43300

10月15日更新：

非常感谢所有的build议。 我正在从系统的一个区域调查到另一个区域。 很难find一个理由。

我想知道2件事情。 1）为什么强大的工具，如strace，auditctl和perf脚本不能追查谁造成了杀害？

2）+++杀死了SIGKILL +++真的意味着它从信号中被杀死了吗？

原来的post

我有一个从Ubuntu 12的Java应用服务器通过JNI接口启动的长时间运行的C进程。 我使用JNI接口来启动一个进程而不是通过Java的进程生成器的原因是性能方面的原因。 java进程生成器做IPC的效率非常低，特别是b / c额外的缓冲引入了很长的延迟。

它会被SIGKILL神秘地终止。 我发现的方式是通过strace，它说：“+++杀死了SIGKILL +++”

我检查了以下内容：

这不是一个崩溃。

这不是一个OOM。 没有在dmesg。 我的进程只使用1G内存的3.3％。

Java层没有杀死进程。 如果代码终止进程，我会在JNI代码中logging一个日志，但是没有写入日志来表明这一点。

这不是一个许可问题。 我试图以sudo或其他用户身份运行，这两种情况都会导致进程被终止。

如果我在shell中本地运行进程，一切工作正常。 更重要的是，在我长时间运行的C代码中，我忽略了信号SIGHUP。 只有当它作为Java服务器的subprocess运行时，才会被终止。

这个过程非常耗费cpu资源。 它使用了30％的cpu。 有许多自愿的上下文切换和nonvoluntary_ctxt_switches。

（新的更新）一个重要的事情很可能与为什么我的过程被杀害有关。 如果这个过程做了一些繁重的工作，那么它不会被杀死，但是有时候这个工作并不需要cpu。 发生这种情况之后，过了一会，大约1分钟就会死亡。 它的状态总是S（SleePing）而不是R（Running）。 看来如果 *** 作系统大部分时间处于空闲状态， *** 作系统会决定终止进程，如果进程繁忙，则不会终止进程。

我怀疑Java的GC是罪魁祸首，但是Java永远不会收集与JNI相关的单例对象。 （我的JNI对象绑定到那个单例）。

我被终止的理由困惑。 有没有人有一个很好的build议如何追踪？

PS

在我的Ubuntu的极限 – 结果是：

core file size (blocks,-c) 0 data seg size (kbytes,-d) unlimited scheduling priority (-e) 0 file size (blocks,-f) unlimited pending signals (-i) 7862 max locked memory (kbytes,-l) 64 max memory size (kbytes,-m) unlimited open files (-n) 65535 pipe size (512 bytes,-p) 8 POSIX message queues (bytes,-q) 819200 real-time priority (-r) 0 stack size (kbytes,-s) 8192 cpu time (seconds,-t) unlimited max user processes (-u) 7862 virtual memory (kbytes,-v) unlimited file locks (-x) unlimited

我试图增加限制，仍然不能解决问题。

core file size (blocks,-f) unlimited pending signals (-i) unlimited max locked memory (kbytes,-l) unlimited max memory size (kbytes,-q) unlimited real-time priority (-r) 0 stack size (kbytes,-t) unlimited max user processes (-u) unlimited virtual memory (kbytes,-v) unlimited file locks (-x) unlimited

当我运行cat / proc / $$$ / status时，这是proc状态

name: mimi_coso State: S (SleePing) TgID: 2557 NgID: 0 PID: 2557 PPID: 2229 TracerPID: 0 UID: 0 0 0 0 GID: 0 0 0 0 FDSize: 256 Groups: 0 VmPeak: 146840 kB VmSize: 144252 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 36344 kB VmRSS: 34792 kB VmData: 45728 kB VmStk: 136 kB VmExe: 116 kB Vmlib: 23832 kB VmPTE: 292 kB VmSwap: 0 kB Threads: 1 SigQ: 0/7862 SigPnd: 0000000000000000 Shdpnd: 0000000000000000 SigBlk: 0000000000000004 SigIgn: 0000000000011001 SigCgt: 00000001c00064ee CAPInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff Seccomp: 0 cpus_allowed: 7fff cpus_allowed_List: 0-14 Mems_allowed: 00000000,00000001 Mems_allowed_List: 0 voluntary_ctxt_switches: 16978 nonvoluntary_ctxt_switches: 52120

strace显示：

$ strace -p 22254 -s 80 -o /tmp/deBUG.lighttpd.txt read(0,"sgi11ctT12248'1("...,512) = 113 read(0,"sgi1126211012431224L/377373222D231214"...,512) = 448 sendto(3,"<15>Oct 10 18:34:01 MixCoder[271"...,107,MSG_NOSIGNAL,NulL,0) = 107 write(1,"SGO 2721t12531243273'11242"...,454) = 454 sendto(3,"SGO 341103221254Z/377373R41721!"...,237) = 237 read(0,"sgi11)3t3321224`'1310"...,512) = 512 read(0,"344u2331625734131525427230035130232426321235122536512412253+276J27337R234R362z"...,512) = 311 read(0,"sgi1126211012431224f/377373222d[210"...,"SGO %!t+1243335271B30036"...,8497) = 8497 sendto(3,"SGO 341103221254t/377373R41730131"...,"sgi1126211012431224200/377373222d/200"...,"SGO 341103221254216/377373R417361+"...,"sgi11221t2021224210'1P"...,512) = 159 read(0,unfinished ...) +++ killed by SIGKILL +++

如何在Web应用程序中设置主题？

无法监视安全事件日志

如何逐行运行linux程序

autoconf检查struct flock

有没有什么办法让一个像这样的循环的程序multithreading？

假设你在你的机器上拥有root权限，你可以启用对kill（2）系统调用的审计来收集这些信息。

root # auditctl -a exit,always -F arch=b64 -S kill -F a1=9 root # auditctl -l List_RulES: exit,always arch=3221225534 (0xc000003e) a1=9 (0x9) syscall=kill root # sleep 99999 & [2] 11688 root # kill -9 11688 root # ausearch -sc kill time->Tue Oct 14 00:38:44 2014 type=OBJ_PID msg=audit(1413272324.413:441376): opID=11688 oauID=52872 ouID=0 oses=20 ocomm="sleep" type=SYSCALL msg=audit(1413272324.413:441376): arch=c000003e syscall=62 success=yes exit=0 a0=2da8 a1=9 a2=0 a3=0 items=0 ppID=6107 pID=6108 auID=52872 uID=0 gID=0 euID=0 suID=0 fsuID=0 egID=0 sgid=0 fsg ID=0 tty=pts2 ses=20 comm="bash" exe="/bin/bash" key=(null)

另一种方法是设置内核跟踪，当审计系统可以做同样的工作时，这可能是一个过度的杀手。

如前所述，另一种选择是使用内核跟踪，这可以通过perf工具来完成。

# apt-get install linux-tools-3.13.0-35-generic # perf List | grep kill syscalls:sys_enter_kill [Tracepoint event] syscalls:sys_exit_kill [Tracepoint event] syscalls:sys_enter_tgkill [Tracepoint event] syscalls:sys_exit_tgkill [Tracepoint event] syscalls:sys_enter_tkill [Tracepoint event] syscalls:sys_exit_tkill [Tracepoint event] # perf record -a -e syscalls:sys_enter_kill sleep 10 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.634 MB perf.data (~71381 samples) ] // Open a new shell to kill. $ sleep 9999 & [1] 2387 $ kill -9 2387 [1]+ Killed sleep 9999 $ echo $$ 9014 // Dump the trace in your original shell. # perf script ... bash 9014 [001] 1890350.544971: syscalls:sys_enter_kill: pID: 0x00000953,sig: 0x00000009

最后我找出了原因。

子进程会自杀，这是一个linux内核错误。

细节：

1）子进程自杀，这就是为什么strace / perf / auditctl无法追踪它。

2）创建进程的JNI调用是从Java线程触发的。 当线程最终死亡时，它也正在破坏它创建的过程。

3）在我的代码fork和execve（）一个子进程，我有代码来监视父进程死亡和杀死我的子进程用下面的行：prctl（PR_SET_PDEATHSIG，SIGKILL）; 在b / c之前，我没有特别注意这个标志，它被认为是我的其他项目的最佳实践，从主线程派生子进程。

4）如果我注释掉这个问题，问题就没有了。 最初的目的是在父进程结束后终止子进程。 即使没有这个标志，它仍然是正确的行为。 看起来像Ubuntu的框默认行为。

5）从这篇文章， https://BUGzilla.kernel.org/show_BUG.cgi?ID=43300 。 这是一个内核BUG，在内核版本3.4.0中修复，我的AWS的ubuntu盒子是内核版本3.13.0-29-generic。

我的机器配置：===> Ubuntu 14.04 LTS ===> 3.13.0-29-generic

一些有用的链接的问题：

a） http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

b） 在父线程退出时调用prctl（PR_SET_PDEATHSIG，SIGNAL），而不是父进程退出

c） https://BUGzilla.kernel.org/show_BUG.cgi?ID=43300

总结

以上是内存溢出为你收集整理的谁在Ubuntu服务器上神秘地发送SIGKILL到我的进程全部内容，希望文章能够帮你解决谁在Ubuntu服务器上神秘地发送SIGKILL到我的进程所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。