在 Unix 的早期版本中（例如 Stevens 的《Unix 网络编程》第 63 页，1990 年），init 进程会 fork 出一个子进程来运行 getty。然后 getty 会获取用户名并 exec /bin/login，将用户名传递给它。接下来，login 会要求输入密码，检查凭据，然后执行 /etc/passwd 文件中的内容，通常是一个 shell，例如 /bin/bash。
由于使用了 exec，没有使用 fork，因此 getty、login 和 shell 共享相同的 PID。
现在，在 Linux 上，/bin/login 会 fork 出一个子进程并在其中运行 shell，而父进程仅对子进程进行等待。为什么会这样？它有什么用途？是谁做出了这个决定？我能否让登录进程不使用 fork？
对我来说这很麻烦。我正在使用 forkpty 构建一个伪终端，并在从设备一侧运行 login。我使用 forkpty 的 pid 结果来在子进程中触发信号。当然，我需要的是 bash 的 pid，而不是 login 的 pid。现在这些 pid 不同了，我必须通过 yucky 的“ps -o pid= --ppid LOGINPID”命令在 popen 中追踪 bash 的 pid。
- Stuart
由于使用了 exec，没有使用 fork，因此 getty、login 和 shell 共享相同的 PID。
现在，在 Linux 上，/bin/login 会 fork 出一个子进程并在其中运行 shell，而父进程仅对子进程进行等待。为什么会这样？它有什么用途？是谁做出了这个决定？我能否让登录进程不使用 fork？
对我来说这很麻烦。我正在使用 forkpty 构建一个伪终端，并在从设备一侧运行 login。我使用 forkpty 的 pid 结果来在子进程中触发信号。当然，我需要的是 bash 的 pid，而不是 login 的 pid。现在这些 pid 不同了，我必须通过 yucky 的“ps -o pid= --ppid LOGINPID”命令在 popen 中追踪 bash 的 pid。
- Stuart