[5373] in testers
Re: 9.2.3 on Solaris: /usr/athena/bin/telnet problem on kerberized
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue May 13 22:12:05 2003
From: Greg Hudson <ghudson@MIT.EDU>
To: Oliver Thomas <othomas@mit.edu>
Cc: testers@mit.edu
In-Reply-To: <304B131A-856A-11D7-BE36-000393A3632A@mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 13 May 2003 22:11:58 -0400
Message-Id: <1052878318.29814.15.camel@equal-rites.mit.edu>
Mime-Version: 1.0
On Tue, 2003-05-13 at 13:41, Oliver Thomas wrote:
> ld.so.1: telnet: fatal: relocation error: file telnet: symbol
> setupterm: referenced symbol not found
> Killed
This appears to be a result of linking with -R/usr/ucblib, which we do
for historical reasons which no longer apply. I've submitted a patch to
link without it.
> Interestingly it also seems to exit the shell I ran telnet in.
Presumably it sets its stdin file descriptor non-blocking and doesn't
have a chance to reset it because of its sudden death. This is a
long-standing minor failure of Unix: non-blocking mode is a property of
kernel "open file descriptions" instead of file descriptors, meaning
that setting the non-blocking flag on a file descriptor affects all
processes which share the file descriptor instead of just the one that
cares. That misbehavior is written into a number of standards by now,
so is unlikely to ever get fixed. Even so, shells could guard against
this problem by resetting their stdin to blocking mode when they regain
control of the tty, or by using select() before reading input. But they
don't, because it's rarely a problem; very few processes set stdin
non-blocking, and the ones that do are usually careful to reset it
before exiting if they have a chance.
