lkml.org 
[lkml]   [1996]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: setsid() semantics changed...
Date
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 +


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.090 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site