无法在任务管理器中终止正在运行但显然不可见的进程

Question

我启动了一个无法运行的应用程序，但我无法删除它，因为它仍在运行。我可以打印 PID，但不能使用它终止进程。

~ $ ps ax | grep snappr | awk '{print $1}'
70824
~ $ kill $(ps ax | grep snappr | awk '{print $1}')
-bash: kill: (70832) - No such process

Answer 1

您是否注意到在两次尝试中获得了两个不同的 PID？

考虑一下：如果您键入类似 的命令vi raven.txt，ps ax则将显示一行显示 的命令vi raven.txt。同样，如果您键入类似 的命令grep snappr，ps ax则将显示一行显示 的命令grep snappr。并且，如果您将其输出ps通过管道传输grep snappr，grep则将找到描述自身的行。所以，如果你输入

$ ps ax | grep snappr | awk '{print $1}'

重复，它每次都会打印不同的数字（因为它正在打印 的 PID grep，并且grep每次运行命令时都会得到一个新的、唯一的进程）。

最后，请考虑：在kill知道其参数之前无法执行该命令。要知道其参数，$(ps ax | grep snappr | awk '{print $1}')管道必须已完成。这意味着grep必须已终止¹。因此，kill正在给定grep进程的 PID ，但只有在grep进程终止之后——所以，自然地，它报告“没有这样的进程”。

也许我应该提到没有snappr进程在运行。如果有，您的第一个命令将输出两个数字： 的 PIDsnappr和 的 PID grep snappr。现在，如果snappr正在运行，您的命令可能会开始半正确地运行，我的意思是它可以执行您想要的操作，但也会给出错误消息。如果snappr以 PID 42097grep snappr运行，并以 PID 70848 运行，则kill命令将是kill 42097 70858，这将终止 并通过尝试终止不再存在snappr 的grep进程而获得错误消息。

你可能想要改进这一点。我最喜欢的方式，我在 20 年前发明的，它改变grep到grep "[s]nappr"，它会匹配snappr但不会匹配自身。另一种方法是使用pgrep而不是ps | grep.

¹或者，awk如果grep仅关闭其标准输出，则可以完成。对于 *nix 程序来说，这将是非常不寻常的行为。

Answer 2

简短的回答

不要通过猛砸跳火圈杀snappr同ps，通过管道grep，然后通过管道awk这样的。而是尝试使用pkill;像这样杀死它。没有麻烦或大惊小怪，它的目标基于开箱即用的进程名称：

sudo pkill snappr

更长的答案

不太清楚Snapper如何在系统进程级别上运行，但问题可能是您只获取子进程 ID 而不是父进程 ID。

事实上，我相信您用来获取进程 ID ( ps ax | grep snappr | awk '{print $1}') 的方法将返回连接到的整个进程 ID 列表snappr，无论它是父进程还是子进程。因此，使用它您可能会杀死一个只是子进程 ID 的进程 ID，但父 ID 仍将处于活动状态并能够“生成”另一个子进程来进行补偿。

所以也许你可以做这样的事情来获取你提供给它的任何进程 ID 的最终父 ID 并对其采取行动；它如何工作的简单概念证明：

ps -p [process ID] -o ppid=

在 Bash 中运行该裸命令将为您提供您放入的子进程 ID 的父进程 ID [process ID]。因此，如果子 ID4567的父进程 ID 为，123则命令将是：

ps -p 4567 -o ppid=

这将返回，123。

也就是说，这可能是一种处理流浪进程的危险方式，因为如果您的脚本获取了 的实际父进程 ID snapper，那么该进程 ID 的父进程实际上可能是您自己的 Bash shell。因此，您可能会无意中杀死 Bash shell，而不是snapper在让snapper进程运行的同时将您从系统中删除。

话虽如此，为什么不让你的生活更轻松，pkill像这样运行：

sudo pkill snappr

这将杀死所有连接的进程，snappr而无需任何花哨的命令行杂耍。