0

我已经阅读了glibc手册中关于作业控制的章节，但我想知道当 shell 终止时如何处理剩余的作业。

我想以下步骤（遵循 posix 处理孤立进程组的约定，前两个步骤似乎很明显）：

  • 使用 shell 的 sid 向作业发送 HUP 信号
  • 使用 shell 的 sid 向停止的作业发送 CONTINUE 信号
  • 释放分配给作业数据结构的资源

我的问题是，如果工作继续存在怎么办？

我认为有机会更改他们的会话 ID 以释放 sid 并解除进程组与终端的关联（不确定这是否有意义）

我应该怎么做ioctl(STDIN_FILENO, TIOCSCTTY)才能使会话进程失去控制终端并发送信号？

该怎么办tty？我应该启动登录并将其设置为 tty 的新控制终端进程组吗？

我仍然很困惑，我们将不胜感激。

4

2 回答 2

0
  • 我应该启动登录并将其设置为 tty 的新控制终端进程组吗？

我读了一遍，我认为答案应该是否定的。

对于基于字符的终端，根进程（initd/systemd/launchd 等）为预配置的终端或特定事件分叉并执行 getty。Getty打开终端文件进行读/写，并将std文件描述符与终端相关联，从配置文件设置一个简单的环境并提示输入用户名，然后执行登录该用户名。Login 更改终端的所有权和权限，更改进程的角色（有效和真实的 uid、gid、补充组），并执行登录 shell 当 shell 终止时，它的父进程通过 sigchd 得到通知，然后重新启动getty... 所以 tty 初始化/销毁不是 shell 的任务。

但不确定如何处理幸存的进程组..

于 2018-11-14T00:19:22.233 回答
0

使用 shell 的 sid 向作业发送 HUP 信号

没必要。当 shell（会话领导者）终止时，内核将自己发送一个 HUP 信号。

使用 shell 的 sid 向停止的作业发送 CONT 信号

没必要。内核也会为您发送它;-)

释放分配给作业数据结构的资源

也不需要那个。当进程终止时，内核将释放进程使用的所有资源。

我的问题是，如果工作继续存在怎么办？

我想你可以SIGKILL他们，如果这真的是一个问题。在 unix 中，如果他们处理SIGHUP.

“现代” systemd 采取了不同的方法，完全违背了这种精神，但我不会进入那个；-)

笔记：

在 linux 中，它是kill_orphaned_pgrp()fromkernel/exit.c负责将HUP+发送CONT到会话中所有停止的作业，并且tty_signal_session_leader()from drivers/tty/tty_jobctl.c，调用 viatty_vhangup_session()并且__tty_hangup()负责将 HUP 从前台进程组发送到进程。

于 2018-11-14T01:09:48.603 回答