Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!lll-tis!ptsfa!ihnp4!cbosgd!cwruecmp!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.os.minix
Subject: Re: Process group initialization (was: SIGNAL Handling Problems)
Message-ID: <2542@ncoast.UUCP>
Date: Fri, 22-May-87 00:13:04 EDT
Article-I.D.: ncoast.2542
Posted: Fri May 22 00:13:04 1987
Date-Received: Sat, 23-May-87 16:31:51 EDT
References: <3882@cae780.TEK.COM> <2508@ncoast.UUCP> <1019@ark.cs.vu.nl>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.os.minix
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 72

As quoted from <1019@ark.cs.vu.nl> by rmgtkro@cs.vu.nl (Rob ten Kroode):
+---------------
| >The process group should be the same as the parent process's pid.  The correct
| >fix would not be in the kernel, it should be in init.  After init forks a
| >child but before the child execs getty (login?), the child should setpgrp().
| 
| I don't agree. A process should inherit it's parent's process group (unless
| you put the child in a specified process group). This means I don't check
| 
| The action of setpgrp() is NOT to set the caller's process group to it's pid.
| Setpgrp() has two arguments: a pid, and a process group. Setpgrp() puts the 
| process whith the specified pid in the specified process group (which is
| most of the time the pid).
| I made setpgrp() and getpgrp(), which returns the process group of the
| specified pid. 
+---------------

Cultural differences.  I'm talking about System V setpgrp().  Also, my
description seems a bit convoluted even to me.

(1) As far as I can tell, BSD setpgrp() has to take a pid argument so job
control will work.  In System V terms, the BSD setpgrp() would probably be
regarded a security hole; System V setpgrp() sets pgrp to the current process's
pid.

(2) With the exception of setpgrp() calls, the pgrp is inherited from the
parent.  My comment about ``the parent's pgrp'' was in reference to the
specific situation to which I was responding.

(3) A rough draft of init() code:

	int pid, slot;

	for (slot = 0; inittab[slot].i_id != NULL; slot++)
		switch (pid = fork()) {
		case -1:
			handle the error;
		case 0:
			setpgrp();
			execl("/bin/sh", "INITSH", "-c", inittab[slot].i_proc, (char *) 0);
			handle an error;
		default:
			inittab[slot].i_pid = pid;
		}
	for (;;) {
		pid = wait(&status);
		for (slot = 0; inittab[slot].i_id != NULL; slot++)
			if (inittab[slot].i_pid == pid) {
				same fork code as above;
				break;
			}
/* no error if pid not found, so inherited processes are cleaned up properly */
	}

I modeled this roughly after what I perceive System V /etc/init as doing.
I have no experience with the actual code.  (I *have* seen the INITSH stuff,
though; we use telinit b/c to manage dialin/dialout switching at TDI.)

BTW, is there some special reason that init is in the Minix kernel?  I would
place it as a user process.  (In fact I'd like to rework the Minix kernel
to be more System V-like; in particular, I like the init and inittab for
System V, although I think some changes are needed.)

++Brando
-- 
Copyright (C) 1987 Brandon S. Allbery.  Redistribution permitted only if the
	redistributor permits further redistribution.
		 ---- Moderator for comp.sources.misc ----
Brandon S. Allbery	{decvax,cbatt,cbosgd}!cwruecmp!ncoast!allbery
Tridelta Industries	{ames,mit-eddie,talcott}!necntc!ncoast!allbery
7350 Corporate Blvd.	necntc!ncoast!allbery@harvard.HARVARD.EDU
Mentor, OH 44060	+01 216 255 1080	(also eddie.MIT.EDU)