Messages in this thread |  | | From | (Miquel van Smoorenburg) | Subject | Re: setsid() semantics changed... | Date | 15 Jul 1996 10:00:44 +0200 |
| |
In article <9607132248.AA10394=aeb@zeus-184.cwi.nl>, <Andries.Brouwer@cwi.nl> wrote: >Miquel van Smoorenburg: > >: Now a process that gets spawned by a shell that sets up the process group >: for it (so it's the leader of it's own group, not session) cannot do >: a setsid() anymore because the "if (p->pgrp == current->pid)" check will >: match on itself. > >: I now do a "setpgrp(0, getpgid(getppid()))" before setsid() and that works, >: but I think the check should be > >: if (p != current && p->pgrp == current->pid) >: return -EPERM; > >: But that could easily break POSIX conformance, I don't know... > >You are quite right, and your version is POSIX conformant, not the kernel. > >POSIX 4.3.2.4 reads: > > EPERM The calling process is already a process group leader, > or the process group ID of a process other than the calling > process matches the process ID of the calling process.
Reading this carefully, I see that the current Linux behaviour _is_ Posix compliant; read the first line after EPERM again. It says "The calling process is already a process group leader". So what I did, calling "setpgrp(0, getpgid(getppid()))" first is indeed the right thing to do if you really want to setsid(). I still think it doesn't make sense, but.. I'll attribute a section to the setsid() manpage about this if you want ;) (what is the latest version?)
Mike. -- + Miquel van Smoorenburg + Cistron Internet Services + Living is a | | miquels@cistron.nl (SP6) | Independent Dutch ISP | horizontal | + miquels@drinkel.cistron.nl + http://www.cistron.nl/ + fall +
|  |