Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 Fluke 1/4/84; site fluke.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!microsoft!fluke!joe From: joe@fluke.UUCP (Joe Kelsey) Newsgroups: net.unix-wizards Subject: Hangups about vhangup() Message-ID: <1766@vax4.fluke.UUCP> Date: Thu, 2-Aug-84 16:44:43 EDT Article-I.D.: vax4.1766 Posted: Thu Aug 2 16:44:43 1984 Date-Received: Sat, 4-Aug-84 02:44:10 EDT Organization: John Fluke Mfg. Co., Everett, WA Lines: 31 vhangup() doesn't do ALL of what I want it to do. What it DOES do quite well is turn off I/O to the particular tty in question when someone logs out with background processes still running. Unfortunately, the background process still has the tty in question open, so the various reference count fields associated with the terminal never drop to zero, and if it happens to be set HUPCLS, the tty close routine never gets called to actually hang up the line. This is a problem especially if you have your terminals connected to a port selector (like a Micom 600), since the line won't be automatically disconnected at logout. I've been staring at kernel source all morning and I can't really see any easy way to fix vhangup(). One possibility would be to actually call closef() from within the inner loop of forceclose(), but this might cause problems when the process in question eventually issues its own close(). I can't really tell if it WOULD cause a problem, although I suspect that there are a lot of race conditions possible. If I could substitute a reference to /dev/null somehow that would be the best, but I'm not sure exactly how I would do all this from the kernel without causing lots of trouble. I can think of lots of potential panic()s that could arise here. Does anyone have any good ideas about the best way to try to approach modifying vhangup()s behavior? I guess the practical hack is to modify the shells to toggle DTR just before they exit at logout. This is NOT what I really want - I'm not even sure if I can do that to /bin/sh - I'm sure another hack couldn't hurt csh any! Well, I guess I'll just go back and stare at the kernel code some more. I'll either get a sudden inspiration or maybe just catch up on my beauty sleep! /Joe