Bash脚本仅应杀死已启动的另一个脚本的实例

11

在当前情况下，某个脚本“ calling.sh”会在后台启动另一个脚本“ call.sh”，执行其他操作，休眠一会儿，然后以a终止“ call.sh” pkill called.sh。这很好。

然后，我还想在其他任何时候从其他终端以独立脚本的形式启动“ call.sh” ，无论是在启动calling.sh之前还是之后。这些独立的实例不应被“ calling.sh”杀死。

我该如何实现？直觉说，调用脚本应该能够告诉进程它是从与此同时运行的任何其他同名开始的。

作为变体，“ calling.sh”也可以启动“被调用”，这是“被调用.sh” 的符号链接。这会使上述情况的管理复杂化吗？使用符号链接需要进行哪些特定的警告和调整？

bash process

— XavierStuvw
source

1

我相信不共享是专门为这样的： unix.stackexchange.com/a/450242/323121

— 入寺

27

不要使用该名称杀死它。由于calling.sh脚本正在调用您稍后要终止的进程，因此只需使用$!（from man bash）：

! 扩展为最近放置在后台的作业的进程ID，无论是作为异步命令执行还是使用bg内置命令执行

因此，如果您calling.sh是这样的：

called.sh &
## do stuff
pkill called.sh

更改为此：

called.sh &
calledPid=$!
# do stuff
kill "$calledPid"

— 特登
source

4

只要被调用的.sh不会自行消失，它就应该起作用，因为否则它的pid可能会被重用，从而杀死一个无害且无关的进程。

— Eugene Ryabtsev

2

@EugeneRyabtsev这是一个很好的观点。我猜您也可以检查$calledPid的父PID是的PID called.sh。

— terdon

为了加强答案，这是我发现有助于整理思想的另一种资源：mywiki.wooledge.org/ProcessManagement

— XavierStuvw

18

我不得不从脚本中挑选很多次；当脚本作为复杂的自动计划的一部分被调用时，它会更加有趣。您确实不应该依赖于pkill选择要杀死的脚本之类的东西。

在calling.sh内部，您应该记录已启动作业的PID，并通过PID明确杀死它们。

内部calling.sh：

./called.sh &
called_pid=$!

# Later
kill $called_pid

— 菲利普·库林
source