从Linux编程接口
#include <unistd.h> int setpgid(pid_t pid , pid_t pgid );pid参数可能未指定作为会话领导者的进程。违反此规则将导致错误EPERM。
pid成为会议负责人？可以pid成为组长，为什么？
如果是，则在调用之后setpgid()，最初由进程领导的组中的其他进程将位于哪个组pid中：
pid现在已经失去了流程pid，没有小组组长，或者pgid哪个过程pid更改为？我怀疑第一个可能与该书所描述的相矛盾setsid()：
限制流程组领导者能够调用setsid（）是必要的，因为没有它，流程组领导者将能够将自己置于另一个（新）会话中，而流程组的其他成员仍保留在原始会话中。（将不会创建新的流程组，因为根据定义，流程组负责人的流程组ID已经与其流程ID相同。）这将违反严格的会话和流程组两级层次结构，因此所有成员进程组的“成员”必须属于同一会话。
谢谢。
此行为由POSIX指定（这意味着它适用于所有自称为“ Unix”的对象，而不仅仅是Linux）。http://pubs.opengroup.org/onlinepubs/9699919799/functions/setpgid.html说：
ERRORS [EPERM] The process indicated by the pid argument is a session leader.
规范没有说明为什么存在此规则，但是我相信dbush陈述的基本原理是正确的：会话负责人必须始终是流程组负责人；如果它可以移入另一个流程组，它将不再是流程组负责人，从而违反了不变性。
但是，仅是一个流程组负责人，而不是会话负责人的流程可能会将自己置于另一个流程组中（不再是流程组负责人），然后可能会将自己带出流程组并成为流程组负责人再次。在某些情况下，作业控制外壳实际上必须这样做：请注意规范RATIONALE部分底部的位
setpgid（）的一种非显而易见的用法是允许作业控制外壳将自身返回到其原始进程组（执行作业控制外壳时有效的组）。当作业控制外壳终止或挂起自身时，作业控制外壳会先执行此操作，然后再将控制权交还其上级，以将其上的作业控制“状态”恢复为上级所期望的状态。
POSIX并未解释为什么作业控制外壳首先会更改其过程组，但是有关实施作业控制的GNU C库手册部分填补了这一空白：
当启动通常执行作业控制的Shell程序时，必须小心，以防已从已经执行其作业控制的另一个Shell调用该程序。
交互式运行的子外壳必须确保其父外壳将其放置在前台，然后才能启用作业控制本身。
[...]
子外壳程序通过其父外壳程序放置到前台后，便可以启用自己的作业控制。它通过调用
setpgid将其放入自己的进程组，然后调用tcsetpgrp以将该进程组置于前台来实现此目的。
然后，当然，如果子shell被挂起，则必须再次撤消该操作（例如，Bash具有suspend执行此操作的内置函数）。
还要注意，作业控制外壳并没有建立自己作为会议的领导者，即使它不是任何一个子shell。会话由负责设置控制终端的任何程序初始化；该程序通常exec是终端中运行的最外层外壳的父代和标识。例如，在打开伪终端并进行分叉之后，但在-ing将在该终端窗口中运行的程序之前，xterm调用setsidexec。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句