From owner-freebsd-stable Sat Jan 16 11:56:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15939 for freebsd-stable-outgoing; Sat, 16 Jan 1999 11:56:10 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from vine.vine.com (vine.vine.com [204.188.68.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15933 for ; Sat, 16 Jan 1999 11:56:08 -0800 (PST) (envelope-from ksh@vine.vine.com) Received: (from ksh@localhost) by vine.vine.com (8.8.8/8.8.8) id LAA29704 for freebsd-stable@freebsd.org; Sat, 16 Jan 1999 11:56:04 -0800 (PST) (envelope-from ksh) From: "Kent S. Harris" Message-Id: <199901161956.LAA29704@vine.vine.com> Subject: setpgid(2) doesn't work as advertised To: freebsd-stable@FreeBSD.ORG Date: Sat, 16 Jan 1999 11:56:04 -0800 (PST) Organization: Vine Technology X-Phone: 408-996-1294 X-URL: http://www.vine.com/ X-Pgp-Key-Location: http://www.vine.com/pgpkey.html X-Pgp-Key-Fingerprint: 16 D1 43 18 03 0D AD E7 F0 D8 DA 86 CA 2D 0B 4E X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Perhaps the wrong forum for this, but I'm not a subscriber to freebsd-bugs. The manual page for setpgid(2) is wrong. It claims the target process must either be a child of the invoker OR have the same effective user-id. That is wrong. If the target is not a child of the process, setpgid(2) will return ESRCH (see kern_prot.c). I believe the manual is correct and the kernel code is wrong. Frequently in industrial situations, an "area controller" process on a particular CPU will spawn a number of sub-processes that perform various tasks such as control special devices. One of the tasks of the "area controller" is to reap its children and re-spawn them should they unexpectedly abort. So far no problem. However, in a situation where the "area controller" aborts and is restarted (usually manually), it may want to reclaim its original children to the process group so it can once again reap the SIGCHLD signals. To do so it must insert the children into its new process group via setpgrp. No can do. Comments? - Kent Harris --- Kent S. Harris | http://www.vine.com/ | Networks, WWW Security, Real Vine Technology | mailto:ksh@vine.com | Time Systems, ASIC Modeling, (408)996-1294 | IEEE ACM USENIX | Custom Hardware/Software To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message