kseshadr@cmdfs2.intel.com (Kishore Seshadri~) (11/24/88)
I'm trying to write a auto-logout facility and am using vhangup to reinitialise a users tty. This does some bizarre things, and several people have suggested that I kill the users shell process instead. I was wondering if anyone had any experiences( pleasant or unpleasant) with the vhangup() call. I'd appreciate any suggestions...
chris@mimsy.UUCP (Chris Torek) (12/02/88)
In article <13@cmdfs2.intel.com> kseshadr@cmdfs2.intel.com (Kishore Seshadri~) writes: >I was wondering if anyone had any experiences( pleasant or unpleasant) >with the vhangup() call. I'd appreciate any suggestions... Among other things, the vhangup() system call should disappear from POSIX-based systems. It will be gone from 4.4BSD. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jbw@bucsb.UUCP (Joe Wells) (12/03/88)
In article <13@cmdfs2.intel.com> kseshadr@cmdfs2.intel.com (Kishore Seshadri~) writes: >I was wondering if anyone had any experiences( pleasant or unpleasant) >with the vhangup() call. I'd appreciate any suggestions... This reminds me of a good quote: Whoa! Don't look at vhangup(2) immediately after eating food. I think this is by Chris Torek ... -- Joe Wells INTERNET: jbw%bucsf.bu.edu@bu-it.bu.edu UUCP: ...!harvard!bu-cs!bucsf!jbw
keith@mit-vax.LCS.MIT.EDU (Keith Packard) (12/03/88)
In article <2246@bucsb.UUCP> jbw@bucsf.bu.edu (Joe Wells) writes: >In article <13@cmdfs2.intel.com> kseshadr@cmdfs2.intel.com (Kishore Seshadri~) writes: >>I was wondering if anyone had any experiences( pleasant or unpleasant) >>with the vhangup() call. I'd appreciate any suggestions... > >This reminds me of a good quote: > > Whoa! Don't look at vhangup(2) immediately after eating food. Admittedly, the vhangup code in 4.3 is terrible. But, it can be made very useful. The current code turns off read/write bits in the file table. A big mistake, as the file remains "open", which causes the carrier to remain up and other problems. The "fix" I wrote was to redirect these file entries to /dev/null (or, failing that, to / with write turned off) by faking an open. This and some other surgery in the device drivers solved most of the dialin troubles on that machine. Removing vhangup isn't going to make the problem go away; either you kill all processes with open descriptors on the device, or you use a kludge like vhangup and keep them alive. Keith Packard keith@expo.lcs.mit.edu
jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/05/88)
In article <5197@mit-vax.LCS.MIT.EDU> keith@expo.lcs.mit.edu (Keith Packard) writes: >Admittedly, the vhangup code in 4.3 is terrible. But, it can be made very >useful. The current code turns off read/write bits in the file table. A >big mistake, as the file remains "open", which causes the carrier to remain >up and other problems. Why can't the file just be closed? Why wasn't this done? How come I wasn't consulted ;-) ? -- John F. Haugh II +-Cat of the Week:--------------_ /|- VoiceNet: (214) 250-3311 Data: -6272 |Aren't you absolutely sick and \'o.O' InterNet: jfh@rpp386.Dallas.TX.US |tired of looking at these damn =(___)= UucpNet : <backbone>!killer!rpp386!jfh +things in everybody's .sig?-------U---
chris@mimsy.UUCP (Chris Torek) (12/05/88)
In article <9124@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) asks: >Why can't the file just be closed? Why wasn't this done? Here is how vhangup() is currently implemented: for (f in file_table) if (f->f_type is an inode) if (f as an inode is a device && is u.u_ttyd) f->f_flag &= ~(FREAD|FWRITE); Simple, if unelegant. Suppose we were to try to close it: if (f device is u.u_ttyd) xxx xxx cannot simply be `closef(f)'; the other process's u. area still refers to f. If the same file table slot is later used for (say) /etc/passwd, all sorts of things might go wrong. Besides, this file table entry might be referenced from any number of u.u_ofile[] entries. (In fact, it will have f->f_count such references.) What we can do is swap: oldip = NULL; newip = inode_for("/dev/null"); for (f in file_table) if (f->f_type is an inode) if (f as an inode is a device && is u.u_ttyd) { oldip = (struct inode *)f->f_data; f->f_data = (caddr_t)newip; } /* oldip==NULL => caller did not have control terminal open */ if (oldip) error = closei(oldip dev, mode, flag); except that this is not quite all that needs doing. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris