我什么时候不应该取消-9进程?


401

我总是很犹豫要运行kill -9,但是我看到其他管理员几乎都在定期运行。

我认为可能存在明智的中间立场,因此:

  1. 什么时候以及为什么要kill -9使用?什么时候,为什么不呢?
  2. 在做之前应该尝试什么?
  3. 什么样的调试“挂起”过程可能会引起更多问题?

7
一个很好的相关的答案
jw013

Answers:


362

通常,您应该在()之前使用killkill -s TERM或,在大多数系统上为),为目标进程提供一个在其自身之后进行清理的机会。(进程不能捕获或忽略,但是它们可以捕获并经常捕获。)如果您没有给该进程完成其运行和清理的机会,它可能会在其周围留下损坏的文件(或其他状态)。重新启动后将无法理解。kill -15kill -9kill -s KILLSIGKILLSIGTERM

strace/ trussltrace并且gdb通常是在寻找原因被卡住的过程被卡住好主意。(truss -u在Solaris上特别有用;我发现ltrace经常以不可用的格式为库调用提供参数。)Solaris上还有/proc一些基于工具的有用工具,其中一些已移植到Linux。(pstack通常很有帮助)。


67
令人信服的原因是,如果您习惯于发送SIGKILL,那么当您进入某个程序时,例如,它将破坏您或您的公司的重要数据库时,您真的会后悔。 kill -9作为最后手段的终结者,它的用途是强调最后手段;在最后解决方案之前使用它的管理员a)不太了解自己是否是管理员,并且b)不应在生产系统上使用。
弓箭2011年

9
@Mikel要解决的另一件事,有时最好是诱使应用程序对SIGINT / SIGTERM不响应,并使用SIGQUIT或SIGSEGV之类的信号清理自身。例如,全屏3D应用程序甚至Xorg。使用SIGQUIT,它没有机会清理任何东西,而是诱使它认为发生段故障,并且感觉它别无选择,只能清理并退出。
penguin359'4

12
@Arcege您是否认为使用被-9杀死的数据会损坏的数据库毕竟值得使用?iirc,mysql,bdb,pg等...在被-9杀死时都表现良好。
dhruvbird 2014年

13
killall -9 java ftw
dmourati 2014年

23
@dhruvbird:仅仅因为您的数据库配备了防弹背心,并不意味着您不需要射击它们。尽管您认为它不像Arcege所说的那样危险是对的,但我认为他的观点仍然是认为它有风险,应该是万不得已。
iconoclast 2014年

228

兰德尔·施瓦兹(Randal Schwartz)过去经常在列表上张贴“(x)的无用”。一篇这样的帖子是关于kill -9。它包括原因和遵循的配方。这是重建的版本(在下面引用)。

(可憎行情)

不不不。不要使用kill -9。

它并没有给过程一个干净的机会:

1)关闭插座连接

2)清理临时文件

3)告知其孩子将要消失

4)重置其终端特性

等等,依此类推。

通常,发送15,然后等待一两秒钟,如果不起作用,则发送2,如果不起作用,则发送1。如果不起作用,请删除二进制文件,因为程序的行为不当!

不要使用kill -9。不要带出联合收割机只是为了整理花盆。

Usenet的另一无用用途,

(。签名)


12
进程终止时,操作系统是否不会关闭任何打开的文件描述符(包括套接字)?
布莱恩·戈登

3
是的,它会的。但是,假设您要杀死连接了客户端的服务器进程,那么客户端将不会在超时之前注意到服务器已关闭。
比昂·林德奎斯特

45
嗯,是旧的“如果它在任何方面都不完美,那么使用它就是愚蠢的”论点。
Timmmm 2014年

3
如果问题的过程是您公司的生产,还是愚蠢的使用
Warren P

3
如果某个进程被杀死,则套接字将向该对等方发送RST,就像该进程在套接字上调用close或shutdown一样,然后套接字将发送FIN。无需超时。仅在断电或断开网络电缆的情况下才会发生超时情况。
ctrl-alt-delor

78

这样做应该总是可以的kill -9,就像通过拉动电源线来关闭它总是可以的一样。它可能是反社会的,需要做一些恢复工作,但它应该起作用,并且是不耐烦的动力工具。

我说这是首先尝试普通杀死(15)的人,因为它确实使程序有机会进行一些清理–也许只是写到“退出sig 15”的日志中。但是我不会接受关于杀死-9的不良行为的任何投诉。

原因:很多客户都喜欢程序员喜欢而不喜欢的事情。随机kill -9测试是一个很好且公平的测试方案,如果您的系统不处理它,则您的系统已损坏。


2
您如何测试“随机杀死-9”?当您杀死-9时,您就完成了。
卡雷尔·比列克(KarelBílek)2014年

18
@Karel:您将测试系统是否可以在此之后恢复,并清除SIGKILL时正在处理的所有混乱事务。
Tadeusz A.Kadłubowski14年

7
这是不正常做kill -9,就像它是不正常拔出插头了。当然,在某些情况下您别无选择,这应该是不得已的选择。当然,拔电源线或kill -9不会产生不利影响,例如根本阻止应用程序或OS正常重启,但是发生这种情况并使用建议的方法(kill [-15])或定期关机将有助于避免因以下情况而发生的混乱情况:您通常会以这种方式中断程序和操作系统。无论如何,无论代码的健壮性如何,始终都有丢失数据的风险。
jlliagre 2014年

7
我怀疑Michael所说的“确定”的意思是您的程序应该优雅地处理这种情况,并且能够在重新启动时进行某种形式的清除。例如,清理PID文件等,而不仅仅是将其玩具扔出婴儿车并拒绝启动。
gerryk 2014年

2
@gerryk他们的确应该这样做,但问题是无论情况和环境如何,有人都会以“杀死-9的许可证”来回答。这是一种不负责任的态度。
jlliagre 2014年

39

我使用kill -9的方式与将厨房用具扔到洗碗机中的方式几乎相同:如果厨房用具被洗碗机破坏了,我就不要了。

这同样适用于大多数程序(甚至数据库):如果我不能没有事情会失控杀了他们,我真的不希望使用它们。(并且,如果您碰巧使用了其中一种鼓励您假装它们没有持久化数据的非数据库之一:那么,我想是时候开始考虑自己的工作了)。

因为在现实世界中,东西可能会由于任何原因随时掉落。

人们应该编写可承受崩溃的软件。特别是在服务器上。您应该学习如何设计假设事情会破裂,崩溃等的软件。

桌面软件也是如此。当我想关闭浏览器时,通常需要AGES才能关闭。有没有我的浏览器需要做的应该比大多数几秒钟。当我要求它关闭时,应该设法立即执行此操作。如果不是,那么,我们拿出kill -9并使其成功。


4
我同意应该编写一个能够容忍这种失败的程序,但是我认为这样做仍然是一种不好的做法。数据库将恢复,但是它可能会检测到粗鲁的中止,然后在重新启动时触发大量的恢复检查。流程正在处理的请求又如何呢?它们将立即被切断,客户端可能也有错误并且也失败了?
Daniel James Bryars

3
不能随时杀死的数据库不是适当可靠的数据库。如果需要一致性,这是一个非常基本的要求。至于客户端:如果在断开连接时他们陷入混乱并破坏了数据,那么它们的设计也很糟糕。解决服务丢失的方法是通过冗余和自动故障转移/重试策略。通常,对于大多数系统而言,快速故障胜于尝试恢复。
borud

4
@borud可能不是完美编写的软件,但它是人们一直使用的软件。哪些系统管理员总是能够选择写得很好的软件,而总能从突然的中断中恢复正常呢?不太多。我个人使用关机脚本,并以此启动/停止进程。如果他们不响应关闭脚本(该脚本会对进程发出适当的信号),我将杀死-9。
Steve Sether 2014年

2
就工具而言,烹饪基本食材和更复杂的菜肴之间没有区别。区别在于厨师。(但是,如果您花费与我一样多的时间做饭,您就会意识到健壮性是厨房工具的最低要求,并且大多数向消费者出售厨房用品的人不会从一个好的工具中知道一个坏的工具。)
borud

1
所以您鼓励人们草率,因为很难正确地做事?越来越多的软件在短暂的操作环境中运行。如果您编写的软件在无法正常关闭的情况下变得繁琐,那么您将很难说服雇主雇用您作为开发人员。
博鲁德(Borud)'18年

10

在其他所有答案中都没有提到的是kill -9,当某个进程无法终止时,它根本不起作用<defunct>

如何杀死其父级为init的<defunct>进程?

什么是进程已失效的,为什么它不会被杀死?

因此,在尝试运行kill -9某个<defunct>进程ps -ef以了解其父代之前,先对其父代执行-15(TERM)或-2(INT),最后执行-9(KILL)。

注: 什么ps -ef

以后的编辑和警告:杀死进程,其父级或子级时要格外小心,因为它们可能会使文件打开或损坏,连接未完成,可能损坏数据库等,除非您知道kill -9该进程的用途,否则只能将其用作最后的手段,如果您需要执行kill命令,请在使用前使用上面指定的信号-9 (KILL)


6

永远永远不要做一个kill -9 1。另外,请避免对某些进程(如mount`)执行kill操作。当我不得不杀死许多进程时(例如,X会话被挂起,而我必须杀死某个用户的所有进程),我就颠倒了进程的顺序。例如:

ps -ef|remove all processes not matching a certain criteria| awk '{print $2}'|ruby -e '$A=stdin.readlines; A.reverse.each{|a| puts "kill -9 #{a}"}'|bash

请记住,kill这不会停止进程并释放其资源。它所做的只是向进程发送SIGKILL信号;您可能会遇到一个挂起的进程。


1
反对者是其他人。但是哪些资源没有释放?您只是意味着该进程无法执行其正常清理吗?那文件锁,信号灯等等呢?你能详细说明吗?
Mikel

看来至少必须清理SysV共享内存和信号量。 archives.postgresql.org/pgsql-general/2006-10/msg01065.php
Mikel

8
这个答案部分令人困惑,部分错误。kill -9 1在大多数联合国机构中只是被忽略了。无需避免kill -9for mount,但也没有意义。我不知道“颠倒流程顺序”是什么意思。kill -9确实停止了进程(例如杀死进程),却没有机会抱怨,但是,如果进程处于不间断的系统调用中,则不会立即终止进程。使用杀死进程kill -9不会释放大多数资源,但不会释放全部资源。
吉尔斯

5

故意杀死进程不是一个平稳的举动:数据可能会丢失,设计不当的应用程序可能会以微妙的方式破坏自身,这些方式只有重新安装才能修复。给定情况。以及有什么风险。用户应该了解某个进程正在执行或应该执行的操作以及它的约束条件(磁盘IOPS,rss / swap),并能够估算长时间运行的进程应花费的时间(例如文件副本, mp3重新编码,电子邮件迁移,备份,[您最喜欢的时间在这里]。)

此外,发送SIGKILL给pid并不能保证将其杀死。如果卡在系统调用中或已被僵尸(Zin ps),则可能会继续被僵尸。^ Z通常是一个长期运行的过程,bg在尝试之前忘记kill -9了。一个简单的方法fg将重新连接stdin / stdout并可能解除阻塞该进程,通常随后该进程终止。如果卡在其他地方或处于其他形式的内核死锁中,则只有重新启动才能删除该进程。(僵尸进程在SIGKILL由内核处理后已经死了(不会再运行用户级代码),通常是内核原因(类似于“阻塞”等待系统调用完成)导致进程未终止。)

另外,如果您想杀死一个进程及其所有子进程,请养成kill使用否定PID进行调用的习惯,而不仅仅是PID本身。有没有担保SIGHUPSIGPIPESIGINT或其它信号清理后,并具有一堆六亲不认进程清理(记得杂种?)是烦人的。

额外的邪恶:kill -9 -1kill -9 1(如果您不是root的人,除非您想看到在扔掉的,不重要的VM上会发生什么),否则更具破坏性


3

为什么您不希望kill -9正常处理

根据man 7 signal

无法捕获,阻止或忽略信号SIGKILL和SIGSTOP。

这意味着接收到这些信号之一的应用程序无法“捕获”它们以执行任何关闭行为。

kill -9在流程上运行之前应该做什么

您应该确保在将信号发送到进程之前,您已经:

  1. 确保过程不忙(即做“工作”);将a发送kill -9给进程实际上会导致该数据丢失。
  2. 如果该进程是无响应的数据库,请确保已首先刷新其缓存。一些数据库支持向进程发送其他信号,以强制刷新其缓存。

3

我创建了一个脚本来帮助自动解决此问题。

它基于我的完整答案2,该问题与stackoverflow非常相似。

您可以在那里阅读所有说明。总之我会建议刚SIGTERMSIGKILL,甚至SIGTERMSIGINTSIGKILL。但是,我在完整答案中提供了更多选项。

请随意从github 仓库中 下载(克隆)它以杀死1

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.