Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site druxy.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!drutx!druxy!jas From: jas@druxy.UUCP Newsgroups: net.unix-wizards Subject: Re: background processes under 4.2bsd Message-ID: <1013@druxy.UUCP> Date: Tue, 28-Feb-84 23:20:20 EST Article-I.D.: druxy.1013 Posted: Tue Feb 28 23:20:20 1984 Date-Received: Fri, 2-Mar-84 07:12:51 EST References: <989@druxy.UUCP> <5319@umcp-cs.UUCP> Organization: AT&T Information Systems Laboratories, Denver Lines: 52 This is a summary of answers to my question: how do you start a background process under 4.2bsd that is guaranteed to terminate when you log out? Recap: any solution having to do with .logout is no good, because csh inexplicably fails to look at .logout if the line is dropped. (Actually, it's pretty explicable: csh probably doesn't catch SIGHUP, and never knows what hit it when the line drops.) The background process doesn't get SIGHUP'ed for two reasons: first, csh nohup's background processes. Second, the background process is in a different process group, and is never sent a SIGHUP when the line drops. The plausible solutions fell into two categories. The first involvee putting the process into the background "by hand", more or less as follows: signal( SIGINT, SIG_IGN ); signal( SIGQUIT, SIG_IGN ); if ( fork() ) exit( 0 ); /* Invoke the "background" process here */ csh thinks of this as a foreground job that has terminated. The child process is in the same process group as the login shell, and thus gets the SIGHUP when the line is dropped. The second category involved polling the parent process id periodically. This can even be done entirely from a shell, by doing a ps, where is the process id of the login shell, and checking the exit status of the ps. Oh, yes -- a third solution is to make the Bourne shell your login shell. Conclusions: in my opinion, best summed up by the respondent who wrote, "there is ... confusion between process groups and terminal groups." When a job is put into the background, the connection between it and the control terminal is broken to the extent of ignoring terminal signals. But some connection remains, for having the background process continue running interferes in some unspecified way with users wishing to log onto the terminal whose line was dropped. It is fine for background jobs to be put into a different process group. It is even fine for background jobs not to die when the user logs out, AS A DEFAULT. It is NOT fine for there to be no way to override that default (short of polling for existence of the login shell, which strikes me as ugly) without resorting to C. The problem is further aggravated by csh's buggy handling of .logout. Many thanks to all those who responded; I appreciate the information you've provided. Jim Shankland ..!ihnp4!druxy!jas