ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ltib] CTRL-C over serial console


From: aaron
Subject: [Ltib] CTRL-C over serial console
Date: Wed, 2 Sep 2009 11:13:05 -0500
User-agent: SquirrelMail/1.4.18

I don't know if anyone else has run into this before, but I thought I
would post it for reference since it took me some digging to figure out. 
I had changed my /etc/inittab file to launch a shell instead of the getty
command for the respawn action, and noticed that ctrl-c didn't deliver
SIGINT to the foreground application, so I couldn't kill applications as I
was used to doing.

The line I had was this:

::respawn:/bin/sh

Without changes to busybox or the kernel, ctrl-c functionality can be
restored by assigning a controlling terminal to the shell application.  To
do this, select something other than the default device for busybox, which
is /dev/console.  I changed the line to this:

ttyS0::respawn:/bin/sh

A good explanation is here:

http://lists.busybox.net/pipermail/busybox/2002-June/006397.html

I'll copy the relevant part of the explanation below.

- Aaron

----

It looks like everyone is taking a swing at this one, so I think I'll
join in.  First off, the easiest way I've found to track down why
ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
need a controlling terminal (the TTY column) and a process group.  If
you have a '?' in the TTY column, ctrl-c won't work.  In the past I
have seen this happen because of this code in drivers/char/tty_io.c:
        if (device == SYSCONS_DEV) {
                struct console *c = console_drivers;
                while(c && !c->device)
                        c = c->next;
                if (!c)
                        return -ENODEV;
                device = c->device(c);
                filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console
block */
                noctty = 1;
        }
Note that O_NOCTTY (no controlling terminal) is forced on whenever
/dev/console is opened (noctty = 1).  Possible workarounds:
  1) Run getty on something other than /dev/console.  For example,
     if you console is on the first serial port, run getty on /dev/ttyS0.
     I believe this is the "correct" answer.
  2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
     it has opened the terminal.
  3) You could remove the forcing of noctty on from tty_io.c

    Scott Anderson
    scott_anderson at mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085






reply via email to

[Prev in Thread] Current Thread [Next in Thread]