Controlling Terminal question

Controlling Terminal question

Post by Joe Palumb » Thu, 30 Jul 1992 04:04:27

I have a program that replaces getty:  it conditions a port, then
waits for input for a login.  

It works ok if I start my own executable program, but if I try to
fork & exec 'su -<usr>' to allow a standard login from that port, I
get the following message on the port:

        Reset tty pgrp from <parent-pid> to <child-pid>

If I ignore SIGHUP, I get this 'reset' msg about 24 times, then
the child (su) dies.

if I trap SIGHUP & write a debug-msg to a file, I get the message
2 times, and the child (su) runs on the port, but the parent dies
('Hangup'), after the debug-msg is written.  

        - I'm running on SunOS 4.1.2
        - The port is not configured to run getty.  
        - To dissociate the child from the parent, before
          the exec() call, I do the following:
                - close fd 0,1 & 2.
                - call setsid() to start a new session w this port as
                        the controlling term.
                - open the port 2x for std in/out
                - dup stdout for stderr
        - I condition the port with standard stty settings

Is there something else I need to do to remove the terminal from
the process-group of the parent?  Any help will be appreciated.


1. controlling terminal question

I see this behavior only in solaris
/home/ffdfptz/t >stty &
[1]     16501
/home/ffdfptz/t >
/home/ffdfptz/t >
[1] + Stopped (SIGTTOU)        stty &
/home/ffdfptz/t >fg
ispeed 88840 baud; ospeed 88824 baud; -parity cstopb hupcl loblk
rows = 43; columns = 122; ypixels = 698; xpixels = 986;
quit = <undef>; erase = ^h; swtch = <undef>;
-inpck -istrip icrnl ixoff onlcr
echo echoe echok echoctl echoke
/home/ffdfptz/t >

whenever I run stty in the background I get this. On doing truss...

mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
close(4)                                        = 0
close(3)                                        = 0
munmap(0xEF790000, 8192)                        = 0
    Stopped by signal #27, SIGTTOU, in ioctl()
ioctl(0, STGET, 0x0002643C)                     Err#22 EINVAL
ioctl(0, TCGETS, 0x00026460)                    = 0
        iflag=0016400 oflag=0000005 cflag=037777773375 lflag=0005073
            cc:  003 000 010 025 004 000 000 000
                 021 023 032 031 022 017 027 026 000 000 000
ioctl(0, TCGETX, 0x0002642C)                    Err#22 EINVAL
ioctl(0, TIOCGWINSZ, 0x00026424)                = 0

The map and unmap in the beginning is the dependency shared objects
metting memory mapped and need not be concerned.
Looks like an STGET ( an undocumented "get line options" ) ended up in
receiving SIGTTOU.

As per the man page for termio, a backgroung process can get a SIGTTOU
if it tries to modify the terminal setting.

I m a really confused. If any of you can shed some light....

Sent via
Before you buy.

2. kinux newsserver/gateway, etc

3. Socket/Terminal Control Question

4. seeking apache module for sudden disconnect

5. A question about terminal i/o control.

6. fddi experience?

7. transferring control of terminal to child

8. Kppd Promblem

9. Finding controlling terminal

10. Starting a process without a controlling terminal

11. "unable to write terminal control database"

12. Trouble with open(2) and controlling terminal (A/UX)

13. Control terminal and double fork ...