allbery@ncoast.UUCP (05/15/87)
As quoted from <3882@cae780.TEK.COM> by hubble@cae780.TEK.COM (Larry Hubble): +--------------- | Third and last, the process group is never set to anything. Which means | it is always zero now. I'm not sure what I did is the best answer, but | it works. In mm/forkexit.c when a fork is done, do_fork() now looks to | see if the parent doing the fork is INIT. If it is INIT, a new PRIVATE | variable (process_group) is incremented and put in the process table. | If the parent is not INIT, the child inherits the parents process group. +--------------- 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(). (Okay, I lied; this requires MM to have a setpgrp() system call. Probably it should be added to do_getset(). The action of setpgrp() is to set the caller's pgrp to its pid, and any process should be allowed to do this, so very little if any checking should need to be done.) ++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)
rmgtkro@cs.vu.nl (Rob ten Kroode) (05/18/87)
In article <2508@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >As quoted from <3882@cae780.TEK.COM> by hubble@cae780.TEK.COM (Larry Hubble): >+--------------- >| Third and last, the process group is never set to anything. Which means >| it is always zero now. I'm not sure what I did is the best answer, but >| it works. In mm/forkexit.c when a fork is done, do_fork() now looks to >| see if the parent doing the fork is INIT. If it is INIT, a new PRIVATE >| variable (process_group) is incremented and put in the process table. >| If the parent is not INIT, the child inherits the parents process group. >+--------------- > >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(). >(Okay, I lied; this requires MM to have a setpgrp() system call. Probably it >should be added to do_getset(). The action of setpgrp() is to set the caller's >pgrp to its pid, and any process should be allowed to do this, so very little >if any checking should need to be done.) > >++Brando 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 in do_fork() if the parent is INIT. During initiliation I put INIT in a "special" process-group. In the INIT-program all the children are put in a process group which differs from it's parent. 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. I made these system calls while I was busy imlementing job-control for MINIX. I had to change a lot before it worked properly, but now everything seems to work perfect (I only need a new shell, but I don't have time to write a new one myself). If someone wants the sources of setpgrp(), getpgrp() and/or job-control please let me know (the sources of job-control are a LOT of diff's !). Rob ten Kroode (rmgtkro@cs.vu.nl).
stuart@bms-at.UUCP (Stuart D. Gathman) (05/19/87)
In article <1019@ark.cs.vu.nl>, rmgtkro@cs.vu.nl (Rob ten Kroode) writes: > I don't agree. A process should inherit it's parent's process group (unless agreed. > 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 In my Sys V manual, setpgrp() has no parameters and sets the caller's pgid to it's pid. INIT's pgid is itself. When forking off a login shell, a setpgrp() is done before the exec. Thus, INIT is immune from signals from user process groups. Perhaps 4.3 is different? -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
allbery@ncoast.UUCP (Brandon Allbery) (05/22/87)
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)