-
谁杀死了这个进程(谁杀死了她)
- 网站名称:谁杀死了这个进程(谁杀死了她)
- 网站分类:技术文章
- 收录时间:2025-07-16 15:46
- 网站地址:
“谁杀死了这个进程(谁杀死了她)” 网站介绍
之前文章提到服务器上一个进程启动后不到三分钟就挂掉,到底是什么原因挂掉了,这个问题可以写篇文章了。进程死了,无非就两种可能:自杀,他杀。他杀又包括第三方杀害和系统判死刑。
先来看自杀。
1.自杀
我们以Java为例,Java程序在main方法运行完就会退出,这种属于自杀。或者像下面这样
System.exit();
这样也属于自杀。
比如下面的代码
public class SelfKill {
public static void main(String[] args) throws InterruptedException {
while(true){
Thread.sleep(5000);
System.exit(4);
}
}
}
运行如下:
[koudai@koudai-pc classes]$ java baicai.other.SelfKill
[koudai@koudai-pc classes]$ echo $?4
我们能用shutdownHook来在临死前记日志。
public class SelfKill {
public static void main(String[] args) throws InterruptedException {
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
System.out.println("关闭应用,释放资源");
}));
while(true){
Thread.sleep(2000);
System.exit(4);
}
}
}
执行结果
[koudai@koudai-pc classes]$ java baicai.other.SelfKill
关闭应用,释放资源
可以看到,无论是主动自杀,还是被自杀,shutdownHook都能保持现场。那如果是不支持shutdownHook的语言呢,或者程序里没有做Hook,那我们是不知道的。另外,不只是自杀shutdownHook能触发,它杀shutdownHook也会被触发。
总结下:对于主动自杀,如果我们有使用了shutdownHook,是能记录下自杀时间和现场的。如果是被自杀(恶意后门调用System.exit),并且我们没有做Hook,那对自杀现场是不知情的。代码里一定要有完善的shutdownHook。
主动自杀是我们的主动行为,那怎样避免被动自杀呢?刚才说了,被动自杀一般是恶意调用System.exit导致,一种是开发者加入的后门,一种是脚本小子加入的后门。System.exit导致JVM直接退出,且没有日志可以查询到是哪个类里的代码导致,因此通常情况下需要屏蔽。System.exit是可以被禁止的,方法就是自定义SecurityManager:
public class SelfSecurityManager extends SecurityManager{
@Override
public void checkPermission(Permission perm) {
if (perm instanceof java.lang.RuntimePermission) {
String name = perm.getName();
if (name != null && name.contains("setSecurityManager")) {
throw new SecurityException("System.setSecurityManager denied!");
}
}
}
@Override
public void checkPermission(Permission perm, Object context) {
//
}
@Override
public void checkExit(int status) {
super.checkExit(status);
throw new ExitException(status);//自定义异常
}
}
System.setSecurityManager(new SelfSecurityManager());//main方法中
需要注意的是,你可以自定义SecurityManager,脚本小子也可以自定义。因此光在Java类中自定义SecurityManager是不够的,你需要在JVM启动参数上定义更精细的policy文件,以及保护自己的SecurityManager不被重置。尤其需要注意不要被反射绕过。
2.他杀
前面说了,不只是自杀shutdownHook能触发,以下场景都会触发 ShutdownHook :
- 代码执行结束,JVM 正常退出
- 应用代码中调用 System#exit 方法
- 应用中发生 OOM 错误,导致 JVM 关闭
- 终端中使用 Ctrl+C(非后台运行)
- 主动关闭应用
我们模拟Ctrl+C试试。如下所示
[koudai@koudai-pc classes]$ java baicai.other.SelfKill^C关闭应用,释放资源[koudai@koudai-pc classes]$
可以看到ctrl+C是能被捕获到的。那么kill指令能被捕获吗
[koudai@koudai-pc classes]$ kill 14675[koudai@koudai-pc classes]$ java baicai.other.SelfKill关闭应用,释放资源
可以看到普通的kill是能被捕获的,那么kill -9呢
[koudai@koudai-pc classes]$ ps -ef|grep Kill
koudai 14948 8231 0 00:57 pts/1 00:00:00 java baicai.other.SelfKill
koudai 15235 14640 0 00:58 pts/2 00:00:00 grep --colour=auto Kill
[koudai@koudai-pc classes]$ kill -9 14948
[koudai@koudai-pc classes]$ java baicai.other.SelfKill
已杀死
可以看到kill -9是无法被进程自身所捕获的。
到这里就结束了吗?
真正的问题来了,就算我有shutdownHook能记下临终遗言,但是最关键的是我无法知道是谁杀死了我。尤其是分析某些木马的场景下
如果是系统杀死我的,那一般就是OOM,这种情况也还好。
Linux内核有个机制叫OOM killer(Out Of Memory killer),该机制会监控那些占用内存过大,尤其是瞬间占用内存很快的进程,然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c,当系统内存不足的时候,out_of_memory()被触发,然后调用select_bad_process()选择一个”bad”进程杀掉。
这种OOM,是有日志记录的,可以用下面的方法查看
grep "Out of memory" /var/log/messagessudo
dmesg|grep "Out of memory"
系统杀的,自认倒霉。
最麻烦的是被第三方杀的,比如木马,各种监控脚本,各种sh脚本,我咋样才知道是哪个进程杀的呢?这就需要用到systemtap了。
3.systemtap使用
systemtap是一个用于简化linux系统运行形态信息收集的开源工具。它立足于性能诊断和bug调试,对内核及用户态程序提供了动态追踪功能,用户可以自定探测事件来跟踪程序的运行情况,如函数的调用路径、CPU占用和磁盘IO等一系列可以探测的情况。有了systemtap,可以在程序不修改代码,甚至不用重启就能分析出程序的运行情况。
systemtap 的核心思想是定义一个事件(event),以及给出处理该事件的句柄(Handler)。当一个特定的事件发生时,内核运行该处理句柄,就像快速调用一个子函数一样,处理完之后恢复到内核原始状态。
先来安装它
yum install systemtap systemtap-runtime
stap-prep
stap -e 'probe begin{printf("Hello, World"); exit();}' #测试验证
由于我们并不需要高级功能,所以暂不安装内核符号文件。接下来,我们写一个stap脚本
vim sigmon.stp
# 内容如下
probe begin
{
printf("%-8s %-16s %-5s %-16s %6s %-16s\n",
"SPID", "SNAME", "RPID", "RNAME", "SIGNUM", "SIGNAME")
}
probe signal.send
{
if (sig_name == @1 && sig_pid == target())
printf("%-8d %-16s %-5d %-16s %-6d %-16s\n",
pid(), execname(), sig_pid, pid_name, sig, sig_name)
}
现在我们需要监控某个进程,就这么调用
(base) [root@VM-0-7-centos ~]# stap -x 28262 sigmon.stp SIGKILLSPID SNAME RPID RNAME SIGNUM SIGNAME 2362819 bash 28262 rsyslogd 9 SIGKILL
这样我们就知道28262这个进程是被2362819这个进程,也就是bash所杀死的。
当然,如果不在事前监控,事后我们是拿不到日志信息的。
如果我们即不做ShutdownHook,也不使用systemtap进行监控,仅仅靠操作系统自带日志,那我们是无法保存死亡现场,也很难知道谁是进程killed背后的凶手了
更多相关网站
- 系统运行shell命令时,忘记nohup了,怎么办?
- linux基础命令之write命令(linux write())
- Linux系统 用户信息的显示:users、w、who
- Linux系统上关闭rpc.statd、hpiod服务的方法
- Linux系列:聊一聊 SystemV 下的进程间共享内存
- 删除tcp占用端口(删除tcpip端口)
- Linux 中常用的系统检测命令(linux怎么测试)
- shell——常用命令2(shell常用指令)
- linux基础命令之who命令(linux中who am i)
- Linux系统下使用lsof工具恢复rm命令删除的文件
- Linux系统中的who命令你真的会用吗?
- 耗时很长的程序忘加nohup就运行了怎么办?
- 最近发表
- 标签列表
-
- mydisktest_v298 (35)
- sql 日期比较 (33)
- document.appendchild (35)
- 头像打包下载 (35)
- 二调符号库 (23)
- acmecadconverter_8.52绿色版 (25)
- 梦幻诛仙表情包 (36)
- 魔兽模型 (23)
- java面试宝典2019pdf (26)
- disk++ (30)
- vncviewer破解版 (20)
- word文档批量处理大师破解版 (19)
- pk10牛牛 (20)
- 加密与解密第四版pdf (29)
- iteye (26)
- parsevideo (22)
- ckeditor4中文文档 (20)
- centos7.4下载 (32)
- cuda10.1下载 (22)
- intouch2014r2sp1永久授权 (33)
- usb2.0-serial驱动下载 (24)
- 魔兽争霸全图 (21)
- jdk1.8.0_191下载 (27)
- axure9注册码 (30)
- gitlab日志 (20)