Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!decwrl!decvax!linus!philabs!ttidca!mb
From: mb@ttidca.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: how do I make a process release its terminal?
Message-ID: <356@ttidca.UUCP>
Date: Wed, 28-Jan-87 23:24:59 EST
Article-I.D.: ttidca.356
Posted: Wed Jan 28 23:24:59 1987
Date-Received: Sat, 31-Jan-87 04:07:02 EST
References: <453@vixie.UUCP> <471@bobkat.UUCP>
Reply-To: mb@ttidca.UUCP (The  of all Evil)
Distribution: world
Organization: CitiCorp TTI, Santa Monica, Ca.
Lines: 63

In article <471@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) answers
paul@vixie.UUCP (Paul Vixie Esq)'s question:

>>I see that syslogd, inetd, cron, and the rest do NOT show 'co' as their
>>control terminal; how do I make this happen for me?

with:

>				       So far as I know, you can't get
>rid of the control terminal.  You might try fiddling with the process
>group, although the shell will grab the tty back anyway.

Since the original question was about 4.2BSD, the answer is to use 
the TIOCNOTTY ioctl.

When we were converting from 4.1BSD to 4.2BSD, we had to take a
somewhat different tack.  We had an xns based network (without remote
login capability - normally used for file transfer only) on the 4.1
systems which we brought up on our then sole 4.2 system while
preparing to convert.  To make it convenient for users to try out 4.2
and still be able to work on 4.1 without first logging out from the
4.2 system, I put together an rlogin/rlogind style pair for the xns
based network, but had to deal with the control terminal problem,
which caused a number of problems (including some involving getpass(),
which still has, and probably always has had, a bug in the assumptions
it makes about what fdopen will do/return when passed a -1 file
descriptor).

I couldnt afford the downtime needed to add and test a new ioctl, so I
ended up using the following hack in the rlogind-like program on the
4.1 side:

	{				/* reset detach flag */

		struct proc p;
		int fd,t,pa;
		struct user *up =  (struct user *)( 0x80000000-UPAGES*NBPG);

		int tpgrp; /* turned out I didnt have to use this, but
			      on another system one might have to. */

		fd = open("/dev/kmem",2);

		lseek(fd,up->u_procp,0);
		read(fd,&p,sizeof(p));
		lseek(fd,up->u_procp,0);
		p.p_flag &= ~SDETACH;
		write(fd,&p,sizeof(p));
		close(fd);
	}	
	(void) close(slave);
	setdefaults(0);

While it did the job, it certainly was not a clean way to go.  Among
other things, it would have been better to just write p.pflag, rather
than all of p.  Aesthetically it was broken, but in behavior it wasn't,
so since nothing bad seemed to be happening, and there were lots of
other tasks at hand, I left it as it was, for the couple of weeks it
was needed.

In this case, I needed to be able to have a control terminal that was
the pty I was using.  Something similar to the above could probably be
used for related purposes as well.