Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 (Fortune) 6/7/84; site dmsd.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hpda!dmsd!bass From: bass@dmsd.UUCP (John Bass) Newsgroups: net.unix-wizards Subject: Re: Getting 'getty' to hangup dialup lines. Message-ID: <128@dmsd.UUCP> Date: Mon, 13-Aug-84 21:49:12 EDT Article-I.D.: dmsd.128 Posted: Mon Aug 13 21:49:12 1984 Date-Received: Thu, 16-Aug-84 02:36:49 EDT References: <297@ipms.UUCP> <2479@mit-eddie.UUCP> <2927@watcgl.UUCP> <8096@umcp-cs.UUCP> Lines: 38 Chris, I implemented the equivalent of vhangup in 1977/78 at SRI with a slightly different syntax ... fswtch(old_fd,new_fd) where all references of the inode pointed to by old_fd file descriptor where replaced with the reference to the new_fd file descriptor inode. Init on that system left a watchdog process to adopt all orphan children for accounting reasons, and did the switch when sent a hangup signal or the "getty/login/shell" process terminated. Everything worked fine except for a few programs that didn't die with hangup and looped forever reading dev/null. It was also necessary to sleep for a couple seconds to MAKE SURE the modem or MUX dropped the line ... and it stayed dropped. The action of replacing one inode with a named other was useful also for moving one login session to another terminal line ( a particularly useful feature for a number of reasons). It also enables being able to switch FILES on some running program ... particularly useful for diverting STDIN and STDOUT between pipes of children processes. The fix allowed detached jobs to complete without holding up the line on a mux or modem ... IE last close for a logout really drops DTR all the time. It is useful to implement /dev/die as a modification of /dev/null which generates eof, then SIGHUP, then SIGKILL based on a upage state variable which is incremented for each read to the device for that process. All writes are just like a normal /dev/null action. This action makes it a fatal error to loop on the "terminal input" ignoring SIGHUP and EOF. NOTE: for anyone still running OLD systems ... Part of the problem is that some systems like PDP's without floating point discard hangup signals when trapping for floating point emulation. Other processes which use event driven actions based on SIGNALS have similar problems ... thus on HANGUP ... not every process will get the hangup signal -- NOTE: that this is only a problem for some older systems, most signal handling in newer systems uses a bit map for posting signals. (Back in the OLD days with V5/V6 life was tough ... remember 50 fixes?) John Bass