Description Craig Leres 1999-07-06 02:20:02 UTC

	If the user exists abruptly, tip's "tipout" child can hang
	around forever. Since the lock file doesn't get cleaned up,
	this prevents other users from accessing the target device.

Fix: The tipout child needs to exit if write() fails with EIO. But
	if the device does not output any characters, we won't get to
	this exit so the parent should also arrange for the child to be
	killed when it exits.

RCS file: RCS/tip.c,v
retrieving revision 1.1
How-To-Repeat: 
	Here's how I found this:

	    - slogin to a host
	    - tip to a device
	    - terminate slogin with the "~." sequence
	    - notice that the 2nd tip process still exists
	    - notice that the lockfile still exists
	
	I used truss on the 2nd process. Before terminating we have:

	    syscall sigprocmask(0x3,0x0)
		    returns 18528 (0x4860)
	    syscall read(0x3,0xbfbfd26c,0x400)
		    returns 7 (0x7)
	    syscall sigprocmask(0x1,0x4860)
		    returns 0 (0x0)
	    syscall write(1,0xbfbfd26c,7)
		    returns 7 (0x7)
	    syscall sigprocmask(0x3,0x0)
		    returns 18528 (0x4860)

	After exiting from slogin:

	    syscall read(0x3,0xbfbfd26c,0x400)
		    returns 1 (0x1)
	    syscall sigprocmask(0x1,0x4860)
		    returns 0 (0x0)
	    syscall write(1,0xbfbfd26c,1)
		    errno 5 'Input/output error'
	    syscall sigprocmask(0x3,0x0)
		    returns 18528 (0x4860)
	    syscall read(0x3,0xbfbfd26c,0x400)
		    returns 1 (0x1)
	    syscall sigprocmask(0x1,0x4860)
		    returns 0 (0x0)
	    syscall write(1,0xbfbfd26c,1)
		    errno 5 'Input/output error'
	    syscall sigprocmask(0x3,0x0)
		    returns 18528 (0x4860)
	    syscall read(0x3,0xbfbfd26c,0x400)
		    returns 7 (0x7)
	    syscall sigprocmask(0x1,0x4860)
		    returns 0 (0x0)

	This repeats until all the characters from the device are
	processed and then the process becomes dormant.