我正在为Linux开发代码，并且在Jenkins环境中运行时似乎无法终止进程。
我有测试脚本产生进程并在进行测试时清理它们。其中一个进程也产生并清理其自己的子进程之一。所有＆＃34;清理＆＃34;通过发送SIGINT，然后等待来完成。当从终端运行时，一切正常，除了在Jenkins运行时。
当在 Jenkins 中运行同样的事情时，使用SIGINT杀死的进程不会死亡，并且等待的调用会永久阻塞。这对我的测试造成了严重破坏。我可以更新逻辑以不进行阻塞等待，但我不觉得我应该更改我的生产代码以适应Jenkins。
有什么想法吗？
答案 0 :(得分：0)
答案 1 :(得分：-1)
在测试中，这通常在我从命令行运行测试时起作用，但是当从另一个脚本调用单元测试脚本时几乎总是会失败。坦率地说，这很奇怪......
然后我意识到，当我有迷路过程时，当我用SIGTERM杀死它们时它们确实会消失。但为什么?????
我没有找到100％的确定答案。但从逻辑上考虑一下，如果进程没有连接到终端，那么“终端中断”信号（SIGINT）可能无效......？
在做一些阅读时，我学到的是，基本上，当它是执行进程的 shell 时，SIGINT操作可能被设置为'ignore'。这对我来说是有意义的，因为你不希望命令行中的CTRL-C杀死你所有的后台进程：
当shell“在后台”执行进程时（或当另一个后台进程执行另一个进程时），新执行的进程应忽略中断并退出字符。因此，在shell执行后台进程之前，应将SIGINT和SIGQUIT设置为SIG_IGN。
我们的生产代码不是shell，而是从shell启动，Jenkins使用/ bin / sh来运行东西。所以，这会加起来。
因此，由于SIGINT与TTY的存在之间存在隐含的关联，因此SIGTERM是用于杀死自己的后台进程的更好选择：
应该注意，SIGINT几乎与SIGTERM相同。 （1）
我已经更改了杀死代理服务器进程的代码和Python单元测试代码，以使用SIGTERM信号。现在一切都在终端和Jenkins运行。