controlling terminal question

controlling terminal question

Post by son.. » Sat, 26 Aug 2000 04:00:00



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
stty
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 e*
/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) =
0xEF790000
mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF780000
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....
Thanks
Sony

Sent via Deja.com http://www.veryComputer.com/
Before you buy.

 
 
 

controlling terminal question

Post by Roger A. Faulkn » Tue, 29 Aug 2000 04:00:00



>I see this behavior only in solaris
>-----------------------------
>/home/ffdfptz/t >stty &
>[1]     16501
>/home/ffdfptz/t >
>[1] + Stopped (SIGTTOU)        stty &
>-----------------------------
>whenever I run stty in the background I get this. On doing truss...
>-------------------------------
>    Stopped by signal #27, SIGTTOU, in ioctl()
>ioctl(0, STGET, 0x0002643C)                     Err#22 EINVAL
>ioctl(0, TCGETS, 0x00026460)                    = 0
>ioctl(0, TCGETX, 0x0002642C)                    Err#22 EINVAL
>ioctl(0, TIOCGWINSZ, 0x00026424)                = 0
>---------------------------------------------
>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....

Sorry if you've seen this before.
My worthless news server failed to send my previous
followup outside of Sun.  Anyway...

I examined the Solaris sources and discovered that this is a bug
in the Solaris kernel that has been there since Solaris 2.0.
There is no bug report describing this in the Sun bug reports.

Standard Solaris does not support the STGET and TCGETX ioctl()s
(which is why you see truss showing them return with EINVAL).
Third-party drivers might enable them however, so the stty(1)
command issues them and reports the results if they succeed.

The bug is, down in the kernel in the stream i/o code, there
is an access check that generates SIGTTOU if an ioctl() is
executed that might modify the terminal settings.  It has
a list of ioctl() codes that do not modify the settings.
Any code not in the list is assumed to modify the settings.
Neither STGET nor TCGETX is in the list, so they cause the
generation of SIGTTOU is the process is a background process.

The fix is to make another list, the list of ioctl() control
codes that are known to fail on a stream and do not cause
generation of SIGTTOU for them in the stream access check code.

I filed a bug report about this.  Please submit a customer call
to Sun and tell them to attach it to this bug report:

Bugid: 4366124
Synopsis: STGET and TCGETX issued by stty cause spurious job-control stopping

Meanwhile just don't run stty in the background (sorry).

Thanks,
Roger Faulkner


 
 
 

controlling terminal question

Post by Barry Dea » Thu, 31 Aug 2000 04:00:00


stty controls terminal options.

When you background it thus:

% stty &

It's stdin and stdout and stderr are now not a terminal, a call to
isatty(3C) would return false.
This is why stty gets the signal.

I can't think why you would want to run stty in the background? Don't do
it and your problem will
not exist!


> I see this behavior only in solaris
> -----------------------------
> /home/ffdfptz/t >stty &
> [1]     16501

--

Barry Dean
Senior Computing Officer

 
 
 

1. Controlling Terminal question

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.
--

2. news reader for KDE

3. Socket/Terminal Control Question

4. WANTED: WEB Space for Raven (Linux Magazine)

5. A question about terminal i/o control.

6. newbie: pci ide controller

7. transferring control of terminal to child

8. test

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 ...