Hangups about vhangup()

Joe Kelsey joe at fluke.UUCP
Sat Aug 4 01:57:17 AEST 1984


I have been staring at the code more, and am on the verge of inserting
some new code.  What I am thinking of doing is calling the device close
routine from vhangup() if it detects any processes still running.  Now,
these processes may or may not terminate when they receive the SIGHUP
that vhangup() sends.  If they do, fine.  If they ignore or otherwise
catch SIGHUP, then my original problem occurs.  What I propose to do is
change the vhangup code as follows:

#ifdef FLUKE
	i = forceclose (u.u_ttyd);
	if ((u.u_ttyp -> t_state) & TS_ISOPEN) {
		gsignal (u.u_ttyp -> t_pgrp, SIGHUP);
		/* Insert call to device close routine here */
		printf ("vhangup: dev %d/%d forceclose returns %d\n",
			major (u.u_ttyd), minor (u.u_ttyd), i);
	}
#else
	forceclose (u.u_ttyd);
	if ((u.u_ttyp -> t_state) & TS_ISOPEN)
		gsignal (u.u_ttyp -> t_pgrp, SIGHUP);
#endif FLUKE

As you can see, it also involves a trivial change to forceclose() to
return the number of file descriptors that it found associated with the
device.  I am going to run with the printf statement for a while before
I decide whether or not I need to use the number returned in a
conditional call to the device close or whether the test for the device
being open is sufficient.  It seemed to me that this was the solution
least likely to cause problems with file and inode counts, but still
have the effect of dropping DTR on the line and hanging up the
connection.

Any comments about this proposal?  After I run with the printf in the
kernel for a week or two I'll be able to tell more about how often the
problem really occurs.

/Joe



More information about the Comp.unix.wizards mailing list