linux shell kill信号SIGKILL&&；杀死

我刚刚编写了一个shell脚本来控制模块的启动和停止。在我发现stop命令导致意外事件之前，一切似乎都正常

我使用命令

kill-s SIGKILL--gpid

杀死一组进程。我使用

/bin/sh

像这样运行命令

/bin/sh-c“kill-s SIGKILL--gpid”

谁回答了这个错误

/bin/sh: line 0: kill: SIGKILL: invalid signal specification 它没有回答任何错误。因此，我总结了bash和sh之间的差异导致结果的解释。但是，当我

ls

调用

/bin/sh

时，我发现

/bin/sh

是指向

/bin/bash

的符号链接，因此命令应该是相同的

我发现命令语法

kill-s SIGKILL

不符合建议的语法，

kill-s kill

建议的语法

所以我用KILL替换了SIGKILL，命令是

kill -9 -$gpid

/bin/sh-c“kill-s kill--gpid”

---

它没有回答任何错误。如上所述，任何人都可以解释这种情况。

当bash作为

sh

调用时（例如，在您的案例中，通过符号链接），它使用

sh

兼容模式，其中大多数现代功能被关闭。我敢打赌

sh

正在调用

kill

的外部二进制文件，它不能识别

SIGKILL

，但是bash调用使用了它的内置代码，而内置代码可以识别。

编写此命令的唯一真正可移植的方法是

kill -9 -$gpid

在90年代中期冻结了shell实用程序的unix上，没有一种指定信号名而不是信号号的方法起作用，除了Linux和开源bsd，unix基本上是所有的unix。然而，SIGKILL是可靠的9号信号，并且一直如此（从V7开始，如果不是更早的话）

特殊参数

--

也不可移植，在本例中不需要

如果你想更礼貌一点（改为发送SIGTERM），那么使用

---

同样，从V7开始，这个数字一直都是可靠的。

这就是问题所在。快速修复使用

/bin/bash

，因为

sh

无法识别SIGINT或其他功能。

您的发行版是什么？在我的Ubuntu 12.04上，

/bin/sh

实际上指向

/bin/dash

。是否在您的电脑中，它也是

dash

，您可以阅读

bash

？当

bash

作为

sh

调用时（例如，通过符号链接，如您的情况），它会使用sh兼容模式，其中大多数现代功能都会关闭。我敢打赌

sh

正在调用

kill

的外部二进制文件，它不识别

SIGKILL

，但是

bash

调用正在使用其内置的，而该内置的是。@Kevin，bash通过检查其

argv[0]

来做到这一点吗？@Kevin你应该建议作为回答，你不应该使用SIGKILL（-9）。使用SIGTERM（-15）或SIGINT或SIGHUP。使用SIGKILL时，程序无法正确关机，无法删除临时文件，无法关闭套接字，也无法向其孩子发送信号…听起来不错。是否有任何方法可以检查外部kill和内置kill之间的差异，或者有任何方法可以跟踪我提到的命令的执行进度。我发现它无法按上述方式工作，因为您可以使用命令“enable-nkill”禁用内置kill，然后执行同样有效的“kill-s SIGKILL pid”。所以我想这里一定有什么没有提到。