在杀了-CONT <PID>之后发生了什么？

Question

我已经通过kill -TSTP <pid>暂停了一个进程。然后尝试用kill -CONT <pid>继续它。但在过程完成后，控制不再返回到bash。为什么会发生这种事？怎样才能克服这个问题？

我用./name.sh从一个bash (比如说bash-1)启动了这个过程(一个shell脚本)。然后通过bash-2使用命令kill -TSTP <pid>挂起该进程。最后，通过bash-2尝试用kill -CONT <pid>恢复它。但是在shell脚本完成之后，控件不会返回，它只是永远停留在那里。

Answer 1

从shell启动的进程具有与它们关联的控制TTY，它们从shell继承，并且也属于进程组。当使用|在管道中运行多个进程或使用()'s的子subshell表示法时，所有这些进程都以相同的进程组启动。当用户按下暂停击键(通常是键盘上的Ctrl)时，TTY层向当前前景进程组中的所有进程发送SIGTSTP信号，父shell将使用SIGCHLD (或从它对wait()的调用中返回)唤醒，再次处理TTY。shell负责控制前台进程组，因为它控制TTY，shell本身驻留在自己的进程组中。

如果某个进程不是TTY当前前景进程组的一部分，则如果该进程试图从终端读取，则该进程将由带有SIGTTIN的TTY层自动停止。例如，将SIGCONT发送到像vim这样的交互式文本编辑器将恢复它，但当它调用其read()以从键盘获取下一个按键时，它将立即获得一个SIGTTIN。必须使用fg作业控制指令通知shell，它应该在恢复前处理组之前将vim移动到前台进程组，从而从前台删除外壳。

Answer 2

kill -CONT是外壳所不理解的东西。

由于这个原因，它只会继续这个过程，而不会对shell产生任何影响。

这会产生类似于背景过程的结果。

如果您想要继续一个过程，最好调用fg或者如果这不是“当前作业”，请使用jobs列出所有当前作业，如果所讨论的任务是作业#3，则调用fg %3。

请注意，从启动外壳调用kill -CONT和fg之间的区别在于，对于fg，外壳除了发送SIGCONT信号外，还将tty进程组设置为恢复进程的进程组。tty处理组的设置控制信号TSTP、TTIN和TTOU的自动传递。稍后，shell开始等待命令。

但是，如果您从一个不同的shell/tty调用kill -CONT，而不是运行该进程的那个shell/tty，那么很明显，您只需要继续一个外部进程。启动kill -CONT的shell将返回到它的提示符，但您可以看到这一点。