djc@chinet.UUCP (David J. Carpenter) (09/08/86)
I am developing a kind of "auxiliary init" program for SYS V, that spawns gettys for lines just being connected to a data switch. What sequence does /etc/init use to spawn a getty (or whatever)? I guessed at it, but I am having problems getting the process group id, the tty group id, and the controlling terminal (?) right in the resulting child process. I fork, then close fd's 0-2, do a setpgrp(), then three fopens for the terminal line that it will be attached to, then a signal(SIGHUP, SIG_IGN) to ignore the parent dieing, then another fork which does the exec(getty). The intermediate parent then exits, and the SIGHUP signal is set back to SIG_DFL. I have my own getty which doesn't mess with stdin stdout and stderr, but does an ioctl, prints a welcome message, then exec's login. I have a problem where the reulting -sh has a process group id of 0. Then the interrupt key doesn't work (SIGINT). According to the programmer's manual a setpgrp should solve this, but if a add a setpgrp to my getty, then login says "Login incorrect" before asking for the password, because it can't open /dev/tty to read the password. /dev/tty is supposed to related to the process group id. So, how does /etc/init do it? Also, how does /etc/init know which child process has died when it gets a SIGCLD? According to the prog. manual, wait() gives you the status, but not the process number. Perhaps the process number is passed as an additional argument to the signal catching function? Any help is greatly appreciated, -- ...!ihnp4!chinet!qpsn!david David Carpenter [home] (312) 545-8076 [work] (312) 787-9343
jrw@hropus.UUCP (Jim Webb) (09/11/86)
> I am developing a kind of "auxiliary init" program for SYS V, that spawns gettys > for lines just being connected to a data switch. What sequence does > /etc/init use to spawn a getty (or whatever)? It execs "/bin/sh -c exec XXXXXXX" wherever XXXXXXX is the command from /etc/inittab. This allows you to use all of the shell special chars, redirection, etc. Note, however that you *cannot* have a pipe in there; I leave it up to the reader to see why not... > Also, how does /etc/init know which child process has died when it gets > a SIGCLD? According to the prog. manual, wait() gives you the status, > but not the process number. Read further. The wait() syscall does two things. One, which you point out, slams status info into the int pointed to as the argument. It also returns the pid of the child that terminated. Eg: pid=wait(&status); > Perhaps the process number is passed as an > additional argument to the signal catching function? Nope, the only argument passed to the catching function is the signal number. However, since this is UNIX, and full of contradictions, more arguments are passed if it is a hardware induced signal... -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw