tty-less processes with tty's open

tty-less processes with tty's open

Post by Gideon Gla » Thu, 14 Oct 1993 05:08:46



We've been having problems with processes which apparently lose their
controlling tty but who keep that tty open.  (This is on a Sun 670
running SunOS 4.1.2.)  The symptoms are these.  When trying to telnet
into this machine, the login: prompt will be displayed for a short
time (around a second) but then the connection will be mysteriously
closed.  When trying to rlogin to this machine it's even more wacky.
I can rlogin to it, and have all my stuff in my .bash_profile run Ok,
but then when that finishes, the shell echoes "logout" and the
connection is closed.

Apparently, telnetd and rlogind are getting EOF (telnetd when it's
trying to read the login name and rlogind after it runs my shell).  We
can trace the problem to the fact that there are processes running
which, for some reason, have the "next available" tty open, so that
when telnetd/rlogind open these tty's, the open succeeds but then when
they try to read from such a tty, they get EOF.  The "offending
programs" vary.  Sometimes it's mailers (elm, pine, /usr/ucb/mail),
but that's probably because one of the primary uses of this machine is
email.  One time it was even lpr, just sitting there with no
controlling tty but yet with a tty open.  Needless to say, it's a pain
to have to remotely find out what the offending process is with
rsh/lsof/ps and then go kill it.

Does anybody have an explanation or maybe even a solution to this
problem?  Thanks in advance.

Gideon Glass

--
----------==========]]]]]]]]]]          [[[[[[[[[[==========----------

]]]]]]]]]]==========----------          ----------==========[[[[[[[[[[

 
 
 

tty-less processes with tty's open

Post by Barry Margol » Sun, 17 Oct 1993 10:26:03



>Apparently, telnetd and rlogind are getting EOF (telnetd when it's
>trying to read the login name and rlogind after it runs my shell).  We
>can trace the problem to the fact that there are processes running
>which, for some reason, have the "next available" tty open, so that
>when telnetd/rlogind open these tty's, the open succeeds but then when
>they try to read from such a tty, they get EOF.

SunOS's pty implementation has a bug: when deciding whether to allow you
to open a pty master, it only checks whether another process already has
the master open -- it doesn't check whether the slave is in use.  However,
if the slave is in use you won't be able to make it your controlling
terminal.

I've seen this problem with xterm and script, but I don't think I've ever
seen it in rlogin or telnet.  Sun's versions of rlogind and telnetd have
specific checks for the slave being in use, by using an ioctl on the master
that is known to get a certain error if the slave is in use.  Are you
running the standard SunOS in.rlogind and in.telnetd on your system?
--
Barry Margolin
System Manager, Thinking Machines Corp.



 
 
 

1. background processes and open tty's

I have noticed when running a background process in Linux and then logging
out of the shell, that the tty port is still listed as an open file.  This
means the port is no longer available for login(until the background
process is killed).

As an example I created a test script which was started using
'test.pl &'

a 'ps' output shows:
root       728  0.1  0.5  1440   712  p0 S   23:47   0:00 perl ./test.pl

the p0 corresponds to ttyp0 which I am logged in on.
Looking at open files from another session(ttyp3), 'lsof /dev/ttyp0', I get:

COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF INODE NAME
bash    720 root    0u   CHR  4,192      0t0  4350 /dev/ttyp0
bash    720 root    1u   CHR  4,192      0t0  4350 /dev/ttyp0
bash    720 root    2u   CHR  4,192      0t0  4350 /dev/ttyp0
bash    720 root  255u   CHR  4,192      0t0  4350 /dev/ttyp0
test.pl 728 root    0u   CHR  4,192      0t0  4350 /dev/ttyp0
test.pl 728 root    1u   CHR  4,192      0t0  4350 /dev/ttyp0
test.pl 728 root    2u   CHR  4,192      0t0  4350 /dev/ttyp0

Now when I logout out of ttyp0 and run 'lsof /dev/ttyp0' again I get:
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF INODE NAME
test.pl 728 root    0u   CHR  4,192      0t0  4350 /dev/ttyp0
test.pl 728 root    1u   CHR  4,192      0t0  4350 /dev/ttyp0
test.pl 728 root    2u   CHR  4,192      0t0  4350 /dev/ttyp0

However a 'ps' command now shows:
root       728  0.0  0.5  1440   712  ?  S   23:47   0:00 perl ./test.pl

indicating the process is not attached to a tty...however, ttyp0 is now
unavailable for logins.  killing test.pl once again puts ttyp0 in the
queue for logins.

The question is how can I start a process in the background under linux
and not have the tty port tied up after I have logged out.  I don't seem
to have these issues under Solaris or AIX.

tia

s

--
Scott R. Every      "Everything is controlled by a small evil group  
 EMJ Internet       to which, unfortunately, no one we know belongs."

 WWW - http://www.emji.net  Newsletter - http://www.fromthejungle.com

Do you believe in Macintosh? Learn how to help the cause by
subscribing to the "EvangeList" listserver! Send email to:

2. JumpStart load times...

3. creating tty's, mknod, stuck after boot with wrong tty - help

4. Debugging Graphics Applications

5. Re-routing a process's 'tty' output

6. Modem not reacting after logon

7. Why does a process have to have a tty open for stty to work (SysV)

8. pixrect.h in Solaris 2.2

9. How to map a tty port to another tty port

10. opening console for output (redirectable so /dev/tty doesn't work)

11. problems with tty, U469036 - bos.rte.tty.4.3.2.9

12. - can one change tty modes for tty not stdio ?

13. tty, tty... where art thou ...?