![杀死后发生了什么 - 继续?](https://linux22.com/image/87181/%E6%9D%80%E6%AD%BB%E5%90%8E%E5%8F%91%E7%94%9F%E4%BA%86%E4%BB%80%E4%B9%88%20-%20%E7%BB%A7%E7%BB%AD%EF%BC%9F.png)
我已经通过 暂停了一个进程kill -TSTP <pid>
。然后尝试继续kill -CONT <pid>
。但进程完成后,控制权不会返回到 bash。为什么会发生这种情况?以及如何克服这个问题?
我从一个 bash(比如 bash-1)开始使用./name.sh
.然后kill -TSTP <pid>
通过 bash-2使用命令暂停该进程。最后尝试kill -CONT <pid>
通过 bash-2恢复它。但是 shell 脚本完成后,控制权不会返回,它只是永远留在那里。
答案1
从 shell 启动的进程有一个与其关联的控制 TTY,它们从 shell 继承,并且也属于进程组。当在带有 ' 的管道中运行多个进程|
或使用带有()
' 的子 shell 表示法时,所有这些进程都以相同的进程组启动。当用户按下暂停键时,通常Ctrl-Z从键盘,TTY 层将信号发送SIGTSTP
到当前前台进程组中的所有进程,父 shell 会通过 a 唤醒SIGCHLD
(或从调用返回wait()
)以再次处理 TTY。 shell 负责控制哪个进程组在前台,因为它控制 TTY,并且 shell 本身驻留在它自己的进程组中。
如果某个进程不是 TTY 当前前台进程组的一部分,则 TTY 层会自动停止该进程并显示 aSIGTTIN
如果它尝试从终端读取数据。例如,发送SIGCONT
到像 vim 这样的交互式文本编辑器将恢复它,但是SIGTTIN
一旦它调用read()
来从键盘获取下一个按键,它就会立即得到 a 。必须使用作业控制指令通知 shell fg
,它应该在恢复之前将 vim 移动到前台进程组,从而使 shell 不再处于前台。
答案2
kill -CONT
是 shell 无法理解的东西。
因此,它只是继续该过程,而不会对 shell 产生任何影响。
这会产生类似于后台进程的结果。
如果您想继续某个流程,最好致电fg
,或者如果这不是“当前作业”,请使用jobs
列出所有当前作业,然后致电,例如,fg %3
如果相关作业是作业 #3。
kill -CONT
请注意,调用和从启动 shell之间的区别fg
在于,使用 时fg
,shell 除了发送信号之外,SIGCONT
还将 tty 进程组设置为已恢复进程的进程组。 tty 进程组的设置控制信号的自动传送TSTP
,TTIN
和TTOU
。随后 shell 开始等待命令。
然而,如果您kill -CONT
从与运行相关进程的 shell/tty 不同的 shell/tty 进行调用,那么很明显您只是继续执行外部进程。触发的 shellkill -CONT
只会返回到提示符,但您会看到这一点。