gp@picuxa.UUCP (Greg Pasquariello X1190) (12/30/87)
I was wondering if anyone out there could help me with this. I have a process
that needs to set it's own process group, and it's own control terminal. From
what I thought, the terminal device driver would set the process group control
terminal upon the first tty open after the setpgrp() (phew!). Here is a peice
of sample code to show what I am doing (no error checking is done to save space)
:
main(argc,argv)
int argc;
char **argv;
{
char **arg_ptr;
if(!(fork())) {
close(0);
close(1);
close(2):
setpgrp();
tty = open("/dev/tty14",2 | O_NDELAY);
dup(tty)
dup(tty)
arg_ptr = &argv[1];
execvp(argv[1],arg_ptr);
}
wait((int *) 0);
exit(0);
}
When I look at the u area for this process, the control terminal is NOT set
to /dev/tty14. In fact, if I exec ps as the argv[1], it shows the console as
the control terminal for the parent, and no control terminal ("?") for the
child. If you could give me any help, I would greatly appreciate it.
Thanks.
Greg Pasquariellopdb@sei.cmu.edu (Patrick Barron) (01/02/88)
Assuming 4.2BSD-ish Unix, you have to disassociate the current control TTY before you can establish a new one. You do this with the TIOCNOTTY ioctl. --Pat.
pls@sortac.UUCP (Pat Sullivan) (01/06/88)
In article <435@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes: >I was wondering if anyone out there could help me with this. I have a process >that needs to set it's own process group, and it's own control terminal. From >what I thought, the terminal device driver would set the process group control >terminal upon the first tty open after the setpgrp() (phew!). The setpgrp system calls in all versions of System V that I've seen contain the same bug (feature??), which is actually rooted in the tty drivers. The tty drivers do not always completely release their controlling terminal when they are supposed to; this often prevents "setpgrp" from functioning as one would expect. This problem may be eliminated by changing one or two lines in the "close" call of each tty driver and one line in the "setpgrp" call (the exit routine currently cleans up the garbage pointers that the tty drivers leave lying around). I'll be glad to share more details (for AT&T 3B tty drivers only) with anyone who has a source license and is interested in kernel hacking. Much better would be a standard, official resolution, but one does not seem to be forthcoming. =================================================================== Pat Sullivan - {gatech|akgua|ihnp4}!sortac!pls - voice 404-257-7382
simon@its63b.ed.ac.uk (ECSC68 S Brown CS) (01/11/88)
In article <232@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: >The setpgrp system calls in all versions of System V that I've seen >contain the same bug (feature??), which is actually rooted in the >tty drivers. The tty drivers do not always completely release their >controlling terminal when they are supposed to; this often prevents >"setpgrp" from functioning as one would expect. A setpgrp() will fail to work in a process which has already done a setgprp(). This happens most if a login-shell tries to grab a new terminal; it's doomed to failure, because a login-shell is exec'd by the getty program which has already done a setpgrp(). [It might be init that actually does it - I forget]. The really annoying part is that it doesn't *completely* release the control tty - it might be just about bearable if it left the original tty in place, but oh no, it has to leave you hanging in limbo instead. --Simon. -- -------------------------------------------------- | Simon Brown | | Laboratory for Foundations of Computer Science | | Department of Computer Science | | University of Edinburgh, Scotland, UK. | -------------------------------------------------- UUCP: uunet!mcvax!ukc!lfcs!simon ARPA: simon%lfcs.ed@nss.cs.ucl.ac.uk "Life's like that, you know" JANET: simon@uk.ac.ed.lfcs
davel@hpcupt1.HP.COM (Dave Lennert) (01/15/88)
> A setpgrp() will fail to work in a process which has already done a setgprp().
True, but the posted code does a fork() first, which is the only reliable
way to do it, so that it is guaranteed to not already be a process group
leader.
Short of a kernel bug (as some have suggested), the open() will also
fail to assign a new controlling terminal if the opened terminal is
already a controlling terminal for another process group.
This is all assuming System V (which it appears you are using since your
setpgrp() contains no arguments). BSD does this slightly magic differently.
-Dave Lennert HP ihnp4!hplabs!hpda!davel uunet!hpda!daveljh@pcsbst (01/18/88)
Aside from some bugs in the tty line driver of some UNIX* version your program should be the first (!!) program to open the new line! If that is not the problem you should tell us what UNIX version you have and on which kind of engine it runs. Johannes Heuft unido!pcsbst!jh