[lkml]   [2008]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Visible Ctrl-C in latest kernels
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 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) {
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) {

for (i = 0; i < 5; i++) {
write(1, ".", 1);
write(1, "\n", 1);

return 0;

 \ /
  Last update: 2008-08-25 19:39    [W:0.058 / U:0.644 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site