skumar@cbnewsh.ATT.COM (swaminathan.ravikumar) (12/22/89)
If the following program is run you get the following error
message:
"pg cannot reopen stdout"
By reading different sources I found out that a process can
break its control terminal by calling "setpgrp". I don't
understand this 100%. Why should the process lose the control
terminal? why do you need "setpgrp"?
I know that it is used to group processes to receive
signals. Does this mean that the processes in the group cannot
use stdin/stdout. I would like to hear from anybody who has used
this call in a real application to understand this better.
#include <stdio.h>
main()
{
setpgrp();
system("pg /usr/tmp/junk");
}
Thanks.
-- ravi
skumar@hocus.att.comjik@athena.mit.edu (Jonathan I. Kamens) (12/25/89)
In article <6863@cbnewsh.ATT.COM> skumar@cbnewsh.ATT.COM (swaminathan.ravikumar) writes: >If the following program is run you get the following error >message: > > "pg cannot reopen stdout" > >[asks what the purpose of setpgrp is] > > #include <stdio.h> > > main() > { > setpgrp(); > system("pg /usr/tmp/junk"); > } Well, since you're posting from AT&T, I assume you're using SysV of some sort, rather than BSD :-). Therefore, I don't know how applicable my comments will be to your situation, since I don't know how much of what I will describe below is shared by BSD and SysV. Our man page tty(4) has several sections applicable to this question: ... Process Groups: Command processors such as csh(1) can arbitrate the terminal between different jobs by placing related jobs in a single process group and associating this process group with the terminal. A terminal's associated process group may be set using the TIOCSPGRP ioctl(2): ioctl(fildes, TIOCSPGRP, &pgrp); or examined using TIOCGPGRP, which returns the current pro- cess group in pgrp. The new terminal driver aids in this arbitration by restricting access to the terminal by processes which are not in the current process group; see ``Job Access Control'' below. ... Job Access Control: When using the new terminal driver, if a process which is not in the distinguished process group of its control termi- nal attempts to read from that terminal its process group is sent a SIGTTIN signal. This signal normally causes the members of that process group to stop. If, however, the pro- cess is ignoring SIGTTIN, has SIGTTIN blocked, or is in the middle of process creation using vfork(2)), the read will return -1 and set errno to EIO. When using the new terminal driver with the LTOSTOP bit set in the local modes, a process is prohibited from writing on its control terminal if it is not in the distinguished pro- cess group for that terminal. Processes which are blocking or ignoring SIGTTOU signals or which are in the middle of a vfork(2) are excepted and allowed to produce output. Also, I note that on our system, setpgrp has two arguments, not none; is your setpgrp different, or are you doing something wrong (I honestly don't know which it is.)? From our man page: NAME setpgrp - set process group SYNOPSIS setpgrp(pid, pgrp) int pid, pgrp; As for what the setpgrp call is used for, the man page for tty points out the most common use, which is for command processors to control who can get to the terminal and who can't. I hope this helps. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
cpcahil@virtech.uucp (Conor P. Cahill) (12/25/89)
In article <6863@cbnewsh.ATT.COM>, skumar@cbnewsh.ATT.COM (swaminathan.ravikumar) writes: > By reading different sources I found out that a process can > break its control terminal by calling "setpgrp". I don't > understand this 100%. Why should the process lose the control > terminal? why do you need "setpgrp"? setpgrp() is one of the steps that should be executed by a daemon process at initialization time. It does disconnect the terminal from the controll tty and therefore should only be used by programs that no longer wish to be associated with a terminal. Note that it does not disallow the use of stdin/stdout/stderr. These are file pointers that are already connected to file descriptors that read/write to a terminal. However, it does effect the ability of the program to re-connect with the terminal by opening "/dev/tty" (which is exactly what pg tries to do). > I know that it is used to group processes to receive > signals. Does this mean that the processes in the group cannot > use stdin/stdout. I would like to hear from anybody who has used > this call in a real application to understand this better. In reality you shouldn't use setpgrp() unless you want to run without any user interaction on the terminal (i.e. a background process or a daemon process that is supposed to be run in the background). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
rml@hpfcdc.HP.COM (Bob Lenk) (12/27/89)
In article <6863@cbnewsh.ATT.COM> skumar@cbnewsh.ATT.COM (swaminathan.ravikumar) writes: > By reading different sources I found out that a process can > break its control terminal by calling "setpgrp". I don't > understand this 100%. Why should the process lose the control > terminal? why do you need "setpgrp"? > I know that it is used to group processes to receive > signals. Process groups are used in two different ways on different implementations. In System V they are used to group the processes that are logged in on a terminal. In BSD they are used to group processes into jobs. While both versions permit sending a signal to a process group, there are other effects based on the intended usage which may not be expected if you just want to group processes for signals. Disassociating from the controlling terminal is one effect that goes with the System V usage. The effects in BSD include distinguishing one process group as the foreground process group of a tty and restricting access from other (background) processes. The IEEE 1003.1 (POSIX.1) standard includes both types of grouping. The System V style process groups are called sessions, while the BSD style are called process groups. The setpgrp() function is not in POSIX (to permit backward compatibility with either version), but is replaced with the two calls setsid() and setpgid(). Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (12/27/89)
In article <1989Dec24.222740.8645@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: :In article <6863@cbnewsh.ATT.COM>, skumar@cbnewsh.ATT.COM (swaminathan.ravikumar) writes: : :> By reading different sources I found out that a process can :> break its control terminal by calling "setpgrp". I don't :> understand this 100%. Why should the process lose the control :> terminal? why do you need "setpgrp"? : :setpgrp() is one of the steps that should be executed by a daemon :process at initialization time. It does disconnect the terminal from :the controll tty and therefore should only be used by programs that :no longer wish to be associated with a terminal. For instance, in the telecommunications program PCOMM, patterned closely after PROCOMM(tm), the input process originally generated SIGHUP back to the controlling terminal when the dial-out line hung up. I was one of the first to notice the problem, since I have a personal daemon running in background that provides me special services within vi. Adding a setpgrp() to the input routine cleared the problem and was later added by a patch level. The Token Ring NetBIOS software for the NCR Tower has the same problem with nlogin, which allows login sessions across the ring. -- Dan Mercer Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)