joel@intelisc.UUCP (Joel Clark) (09/17/88)
Perhaps someone could explain some odd behavior in the following to programs:
######################## Cut here for foo2.c ##############################
#include <fcntl.h>
main()
{
int pid;
pid = fork();
if (pid == 0){
execl("./foo");
}
sleep(40);
}
####################### Cut here for foo.c ###############################
main()
{
char c;
int i;
printf("start foo\n");
i = read(0,&c,1);
printf("read %d chars\n",i);
write(1,&c,1);
for(;;) {
i = read(0,&c,1);
write(1,&c,1);
if ( i != -1){
printf("input %d chars\n",i);
}
}
}
###################### Cut here ########################################
On a Sun 3/50 running Sun OS 3.5 the child program terminates with no
message, at the read on stdin, as soon the parent terminates. If the child
does not read stdin, it survives. If stdin is closed before the read, read
returns -1.
On Sys V/386 R3.0 the child does not terminate and is able to read any input
the shell does not get. ( i.e. type chars and <cr> quickly so that the child
gets chars while the shell is processing input from previous line.)
This code is much reduced from a large system that uses several daemon process
fileservers.
Why is the child terminating?? How can I work around this so it behaves
on the Sun and it does on Sys V/386 OR AT LEAST returns an error.
Joel Clark joel@intelisc.COM
Intel Scientific Computers
15201 SW Greenbrier Parkway
Beaverton, Or 97006
(503) 629-7732chris@mimsy.UUCP (Chris Torek) (09/18/88)
In article <347@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >On a Sun 3/50 running Sun OS 3.5 the [orphaned] child program terminates >with no message, at the read on stdin, as soon the parent terminates. If >the child does not read stdin, it survives. This happens only if the child's stdin is a tty and SIGTTIN is enabled (this is the default) and the process is started by a shell that understands job control. The child is in a separate process group, and its parent process is /etc/init (pid 1), since it has been orphaned. When it tries to read from a terminal, the tty driver code notices that it is not in the proper process group and sends a SIGTTIN (`stop on tty input') signal so that the ultimate parent shell can take note. Alas, there is no shell; the process is a child of init, and the signal code refuses to allow children of init to stop on keyboard signals, since no one is around to continue them. So the kernel translates the SIGTTIN to a SIGKILL, and kills the process. This is arguably the wrong thing to do, but then, there is not much that is arguably the *right* thing to do in such a situation. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris