Subject: Re: One KUDOS, one bug...
To: jfw , spm <firstname.lastname@example.org>
From: Burgess, David (TSgt) ~U <BurgessD@J64.STRATCOM.AF.MIL>
Date: 03/08/1994 12:22:00
> > > > Ok...now the bug...I was a happy tcsh user until I upgraded today
> > > > yesterday afternoon, built all night)...I open up a telnet window on
> > > > xterm, and log in...and do 'ls' and it looks like:
> > > > yuri (thorpej) ~ 12% ls
> > > > total 74
> > > > 2 Mailers/ 2 amdstuff/ 2 mail/ 2 samples/
> > > > Also...stty intr ^C susp ^Z no longer works...BTW...This stuff all
>I have non-deterministically seen this problem. Never had any problems
>with ^C and ^Z though (bash is my usual shell, but I've tried tcsh also).
Me too, although I never use bash. Tcsh is my primary shell.
> > > > on the console...and it's OK if I rlogin or rsh...So, my guess is
> > > > libtelnet and/or telnetd is hosed. Anybody?
>It's pretty definitely tied up with telnetd and/or your client telnet
>program. (Where do you telnet from?)
It happens to me solely on the console. My telnet and direct connected
terminals never seem to fail this way.
> > ls isn't at fault; somehow the tty modes are either fouled up or being
> > misinterpreted. I've noticed that the interrupt character hasn't worked
>> > suspend character does work (and telnet SEND IP also works, so it isn't
>> signal handling).
>I've never had the interrupt character problem, but the problems
>are almost certainly tied up with telnet's LINEMODE options. Try
>compiling telnetd without -DKLUDGELINEMODE (first), then without
>-DLINEMODE. Also if the client telnet doesn't support LINEMODE at
>all, the problem may not arise, or if the client has proper support
>for LINEMODE, it may work better. (I've seen the same type of
>problems when telnetting to the Cray, where there's even a stty
>-extproc to turn things off). Another related problem is that ~h
>doesn't work right in mail - something that bothered me a lot
>because it seemed to work half the time (when run 'directly' in an
>xterm, as I understand now).
I don't know if this is a meaningful data point, but I have pretty much the
same problems just using tcsh.
It is usually after innd (or most anything else that uses the syslog) tries
to log a message to root. Usually, the message will come through loud and
clear, other times, it will be suppressed.
It seems to happen most frequently when the console is switching from one
mode to another AND a message from the syslogd tries to get shoved through.
It doesn't happen very often, but when it does I usually have a heck of a
time getting the system back to normal. It will also sometimes (but not
everytime) happen when a second console message is suppressed. If the first
was suppressed and the second is suppressed, suddenly none of the keys work
without 'return's and other strangeness. Usually, I end up logging the
console out and logging back in. The application I see it most commonly in
is 'vi'. Note that this is not a completely new problem. I have been
seeing it for several weeks. I am willing to write it off as a bogosity in
tcsh, and just live with it until I get more time to look into it.
If it happens while I am in tcsh (waiting at the prompt, for example), none
of the control characters will work anymore (^Z, ^C, etc.) and programs like
'more' will cease to function ("invalid ioctl for this terminal" sounds
familiar). The problem seems (in my case, anyway) to be solely based on a
problem with a tty mode. Logging out and in seems to be the only way to
fix it. I have tried every combination of recompile, relink, stty resets,
etc that I can think of. I even changed the source for tcsh that problem
with the strange mode when the console is initialized...