April 18th, 2002, 04:39 AM
OpenBSD: Applications not responding to INTR control character
I'm having a relatively trivial (but very weird) problem with my installation of OpenBSD that has now got me pulling my hair out in frustration as I'm all out of ideas as to how to solve it.
Basically, certain applications such as tail don't respond to an INTR generated using (for example), Ctrl-C. If I do `tail -f /var/log/messages`, and then try to break out of that using the usual Ctrl-C sequence, it's ignored. The ^C is echoed to the screen, but it doesn't interrupt tail.
So as you can imagine, this is somewhat annoying. I can generate a QUIT to get out of such a situation but usually it (it being whatever application I'm using at the time) dumps core so it's probably not a good idea.
The only clue I've got to go on is that this doesn't occur locally, only when I'm connected remotely via SSH.
I've tried a multitude of SSH clients (both Windows and UNIX based), and a variety of termtypes but to no avail. I've messed with stty until I'm blue in the face, and still this problem persists. I've also tried different shells including bash, sh, and ksh. Oh, and it occurs with both my kernel and a GENERIC kernel.
I'm running OpenBSD 3.0-STABLE (source synchronised and rebuilt 15/04/02), with OpenSSH_3.1. Below is an output of wsconsctl -a, and an output of stty -a. My /etc/termcap is termtypes.master,v 1.30, and my /etc/ttys is ttys,v 1.16 2001/02/11 - both unmodified.
If there is something else that anyone requires to help diagnose and solve this problem then just let me know and I'll be happy to provide it.
speed 9600 baud; 56 rows; 118 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
iflags: -istrip icrnl -inlcr -igncr -iuclc ixon -ixoff ixany imaxbel
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -onocr -onlret -olcuc oxtabs -onoeot
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
This happens on some SSH clients, but it is indeed strange that you get this with many clients as in my experience, most have support for this.
I can tell you that I, that have a box where I run OpenBSD 3.0-STABLE with no modifications (except the http, ftp and sendmail parts) like you, have no problems like this.
I use SecureCRT for SSH'ing from my windows, and it supports all escape characters. Of the clients I've tried, I like that one the most... Naturally it has some problems aswell, but what program doesnt? The others have more of them....
Hopefully changeing your client will solve your problem.
From your post I assume this happens remotely, not locally.
what is the TERM environmental variable set to once you have logged in?