我已经阅读了glibc手册中有关作业控制的章节，但是我想知道在终止Shell时如何处理其余作业。
我假设执行以下步骤（遵循posix的约定来处理孤立的进程组，前两个步骤似乎很明显）：
我的问题是，如果工作能够生存下去呢？
我认为可能会更改他们的会话ID，以释放sid并使进程组与终端解除关联（不确定是否有意义）
我应该做ioctl(STDIN_FILENO, TIOCSCTTY)来使会话进程失去控制终端并发送信号吗？
如何处理tty？我应该启动登录并将其设置为tty的新控制终端进程组吗？
我仍然很困惑，线索将不胜感激。
答案 0 :(得分：0)
我阅读了，我认为答案应该不是。
对于基于字符的终端，根进程（initd / systemd / launchd等）会为预先配置的终端或在特定事件中分叉并执行。 Getty打开终端文件以进行读取/写入，并将std文件描述符与终端关联，从配置文件设置简单环境，并提示输入用户名，然后执行该用户名的登录。 登录更改终端的所有权和权限，更改流程的角色（有效和真实的uid，gid，补充组），并执行登录外壳 当shell终止时，sigchd会通知其父进程，并重新启动getty。 因此，tty初始化/销毁不是Shell的任务。
还不确定如何处理幸存的过程组。
答案 1 :(得分：0)
使用外壳的sid向作业发送HUP信号
不需要。当外壳程序（会话负责人）终止时，内核将自己发送一个HUP信号。
使用shell的sid向停止的作业发送CONT信号
不需要。内核也会为您发送；-）
释放为作业的数据结构分配的资源
也不需要。进程终止时，内核将释放该进程使用的所有资源。
我的问题是，如果工作能够生存下去呢？
我想您可以SIGKILL，如果确实有问题的话。在unix中，如果他们处理SIGHUP，它们将应该生存。
“现代” systemd采取了完全不同的方式，完全违背了这种精神，但我不会参加;-）
注释：
在Linux中，来自kernel/exit.c的{{3}}负责将HUP + CONT发送到会话中所有已停止的作业，以及kill_orphaned_pgrp()来自drivers/tty/tty_jobctl.c，通过tty_vhangup_session()和__tty_hangup()调用，可用于将HUP从前台流程组发送到流程。