Hi,
A fairly user-level question here.
I recently upgraded from 2.6.24.3 to 2.6.26.3.
I've noticed that on my Debian stable system, I can now see Ctrl-C characters
when using an xterm. I've checked the stty settings and nothing seems
different.
For example:
[cdfrey ~]$ sleep 3s
^C
[cdfrey ~]$
The ^C does not appear using 2.6.24.3.
I'm not sure where to look to find what changed.
I've attached my config for 2.6.26.3, which is basically the same for
2.6.24.3, upgraded with 'make oldconfig'.
This is the output from stty -a. It is the same on both 24.3 and 26.3 kernels.
speed 38400 baud; rows 56; columns 89; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
Which kernel is operating correctly?
Thanks,
- Chris
On Fri, Aug 22, 2008 at 10:15 PM, Chris Frey <[email protected]> wrote:
> Hi,
>
> A fairly user-level question here.
>
> I recently upgraded from 2.6.24.3 to 2.6.26.3.
>
> I've noticed that on my Debian stable system, I can now see Ctrl-C characters
> when using an xterm. I've checked the stty settings and nothing seems
> different.
That is a feature which was introduced in
commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961
Author: Joe Peterson <[email protected]>
Date: Wed Feb 6 01:37:38 2008 -0800
tty: enable the echoing of ^C in the N_TTY discipline
Turn on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g. ctrl-C
will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR).
Linux seems to be the only unix-like OS (recently I've verified this on
Solaris, BSD, and Mac OS X) that does *not* behave this way, and I really
miss this as a good visual confirmation of the interrupt of a program in
the console or xterm. I remember this fondly from many Unixs I've used
over the years as well. Bringing this to Linux also seems like a good way
to make it yet more compliant with standard unix-like behavior.
[[email protected]: coding-style fixes]
Cc: Alan Cox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Are you experiencing a problem related to this?
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
On Sat, Aug 23, 2008 at 11:52:02AM -0600, Joe Peterson wrote:
> Vegard Nossum wrote:
> >> I've noticed that on my Debian stable system, I can now see Ctrl-C characters
> >> when using an xterm. I've checked the stty settings and nothing seems
> >> different.
>
> Vegard, thanks for forwarding this to me.
>
> Chris, yes, what you are now seeing on the newer kernel is correct.
Thanks guys. I was not aware of this change before asking. The change
makes sense. I wasn't having any problems with it, just wondering where
it came from.
Thanks for the enlightenment. :-)
- Chris
Vegard Nossum wrote:
>> I've noticed that on my Debian stable system, I can now see Ctrl-C characters
>> when using an xterm. I've checked the stty settings and nothing seems
>> different.
Vegard, thanks for forwarding this to me.
Chris, yes, what you are now seeing on the newer kernel is correct.
-Joe
On Sat, Aug 23, 2008 at 09:02:32PM -0400, Chris Frey wrote:
> On Sat, Aug 23, 2008 at 11:52:02AM -0600, Joe Peterson wrote:
> > Vegard Nossum wrote:
> > >> I've noticed that on my Debian stable system, I can now see Ctrl-C characters
> > >> when using an xterm. I've checked the stty settings and nothing seems
> > >> different.
> >
> > Vegard, thanks for forwarding this to me.
> >
> > Chris, yes, what you are now seeing on the newer kernel is correct.
>
> Thanks guys. I was not aware of this change before asking. The change
> makes sense. I wasn't having any problems with it, just wondering where
> it came from.
>
> Thanks for the enlightenment. :-)
I would not be surprized that it is what has caused delays for Ctrl-C
to take effect for some of us. As discussed in another thread on the
subject, the problem was relatively recent and not easy to reproduce.
Now we have a patch to try to revert if/when we finally get a reproducible
case.
Willy
Willy Tarreau wrote:
>>> Chris, yes, what you are now seeing on the newer kernel is correct.
>> Thanks guys. I was not aware of this change before asking. The change
>> makes sense. I wasn't having any problems with it, just wondering where
>> it came from.
>>
>> Thanks for the enlightenment. :-)
>
> I would not be surprized that it is what has caused delays for Ctrl-C
> to take effect for some of us. As discussed in another thread on the
> subject, the problem was relatively recent and not easy to reproduce.
> Now we have a patch to try to revert if/when we finally get a reproducible
> case.
It seems very unlikely that the echo has anything to do with it, other
than making the problem more visible. See this post:
http://marc.info/?l=linux-kernel&m=121526224222656&w=2
And to what patch of yours are you referring?
-Joe
Hi Joe,
On Mon, Aug 25, 2008 at 08:00:07AM -0600, Joe Peterson wrote:
> Willy Tarreau wrote:
> >>> Chris, yes, what you are now seeing on the newer kernel is correct.
> >> Thanks guys. I was not aware of this change before asking. The change
> >> makes sense. I wasn't having any problems with it, just wondering where
> >> it came from.
> >>
> >> Thanks for the enlightenment. :-)
> >
> > I would not be surprized that it is what has caused delays for Ctrl-C
> > to take effect for some of us. As discussed in another thread on the
> > subject, the problem was relatively recent and not easy to reproduce.
> > Now we have a patch to try to revert if/when we finally get a reproducible
> > case.
>
> It seems very unlikely that the echo has anything to do with it, other
> than making the problem more visible. See this post:
>
> http://marc.info/?l=linux-kernel&m=121526224222656&w=2
possible, indeed.
> And to what patch of yours are you referring?
not mine, I was speaking about your patch of 2008/02/06 which was
talked about earlier in this thread. I was thinking that it was
possible that the signal got delayed when it was hard to print
^C because the output was already busy spewing a stream of data.
Maybe I'm wrong, but I mean it does not cost much to try to revert
this patch when the problem is encountered. And I keep in mind
that it is possible, as you say, that your patch only makes the
problem more visible.
Regards,
Willy
Willy Tarreau wrote:
> not mine, I was speaking about your patch of 2008/02/06 which was
> talked about earlier in this thread. I was thinking that it was
> possible that the signal got delayed when it was hard to print
> ^C because the output was already busy spewing a stream of data.
> Maybe I'm wrong, but I mean it does not cost much to try to revert
> this patch when the problem is encountered. And I keep in mind
> that it is possible, as you say, that your patch only makes the
> problem more visible.
Actually, funny you mention the case when output is busy. This actually
will not cause any delay of the signal, but it instead causes the echo
(not the signal) to be thrown away in the current code. If the tty
driver's buffer is full, the attempted write simply returns - nothing is
held. The signal is still sent right away.
Now, this loss of the echo is a problem in itself, not because it delays
the signals, but because the echo will not be displayed. Echo is also
lost when the tty is stopped (but the signal chars restart the tty, so
you will only see this for regular chars typed after, say, a ctrl-s)).
I have another patch out that will fix the lost echo issue:
http://marc.info/?l=linux-kernel&m=121924672730143&w=2
Note that this patch also will never cause any delay of the signals. In
fact, it places the echo character in a buffer so that a full or stopped
tty buffer will not cause the echoed char to be immediately discarded.
The signal, same as now, is always immediately issued - no delay.
-Joe
Willy Tarreau wrote:
> I would not be surprized that it is what has caused delays for Ctrl-C
> to take effect for some of us. As discussed in another thread on the
> subject, the problem was relatively recent and not easy to reproduce.
>
I don't think so. Joe Peterson raised A line of enquiry, which looked
quite promising to me, in
http://marc.info/?l=linux-kernel&m=121502197008293. He observed weird
behaviour with pgrp, and that doesn't seem to have been explored
adequately. I think it's worth highlighting that the code which sends
the signal is the following snippet, from n_tty.c:
if (tty->pgrp)
kill_pgrp(tty->pgrp, signal, 1);
I wonder if pgrp has a value different than we expect?
> Now we have a patch to try to revert if/when we finally get a reproducible
> case.
I had an idea; it didn't work out as I expected, but it did produce a
result that I can't immediately explain; and it might be relevant. The
following program, when executed in background (./testprogram &) stops
at tcsetpgrp(), which is fine; and if then continued (fg), it is immune
to the interrupt, quit and suspend keys. However, it is not immune to
those keys if executed in foreground (./testprogram). As said, I can't
immediately explain this, and it seems like it might be important...
#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
main() {
int i;
pid_t pid = getpid();
pid_t ppid = getppid();
int tty = open("/dev/tty", 0);
if (tty == -1) {
perror("/dev/tty");
exit(1);
}
printf("pid %d (pgrp %d), ppid %d (pgrp %d), pgrp %d\n", pid, getpgid(pid), ppid, getpgid(ppid), tcgetpgrp(tty));
if (tcsetpgrp(tty, ppid) == -1) {
perror("tcsetpgrp");
exit(2);
}
for (i = 0; i < 5; i++) {
sleep(1);
write(1, ".", 1);
}
sleep(1);
write(1, "\n", 1);
return 0;
}
David Newall wrote:
> Willy Tarreau wrote:
>> I would not be surprized that it is what has caused delays for Ctrl-C
>> to take effect for some of us. As discussed in another thread on the
>> subject, the problem was relatively recent and not easy to reproduce.
>>
>
> I don't think so. Joe Peterson raised A line of enquiry, which looked
> quite promising to me, in
> http://marc.info/?l=linux-kernel&m=121502197008293. He observed weird
> behaviour with pgrp, and that doesn't seem to have been explored
> adequately. I think it's worth highlighting that the code which sends
> the signal is the following snippet, from n_tty.c:
>
> if (tty->pgrp)
> kill_pgrp(tty->pgrp, signal, 1);
>
>
> I wonder if pgrp has a value different than we expect?
David,
Subsequently, I determined that the issue I talked about in the above
referenced thread was a bug in bash. Here is my post about this:
http://marc.info/?l=linux-kernel&m=121537020432289&w=2
The bash author has developed a simple patch, and it should appear
(according to him) in the new bash version.
> I had an idea; it didn't work out as I expected, but it did produce a
> result that I can't immediately explain; and it might be relevant. The
> following program, when executed in background (./testprogram &) stops
> at tcsetpgrp(), which is fine; and if then continued (fg), it is immune
> to the interrupt, quit and suspend keys. However, it is not immune to
> those keys if executed in foreground (./testprogram). As said, I can't
> immediately explain this, and it seems like it might be important...
When I run your program, foreground or background, it always completes
(i.e. 5 "." chars) - i.e., I cannot interrupt it before it finishes.
This seems different than what you see.
Given the nature of the bash issue, it does not seem related, at least
not directly.
-Joe
Joe Peterson wrote:
> When I run your program, foreground or background, it always completes
> (i.e. 5 "." chars) - i.e., I cannot interrupt it before it finishes.
> This seems different than what you see.
>
> Given the nature of the bash issue, it does not seem related, at least
> not directly.
Ah, but forgot to add: what you are seeing sounds like it warrants
investigation. If you find anything more on this (or if I am not reproducing
your results correctly), let me know.
-Joe
Joe Peterson wrote:
> When I run your program, foreground or background, it always completes
> (i.e. 5 "." chars) - i.e., I cannot interrupt it before it finishes.
>
This is what should occur and what I originally expected to see. I
can't explain why it works (slightly) differently on my machine, but
that's probably unimportant. My thinking is that the issue reported as
^C being delayed could be caused for this sort of reason; it could be a
shell bug, and not a kernel bug.