Originally, "tty" had two definitions: the hardware (now the emulator) and the driver (interfaced through /dev/pty* or /dev/tty*).
The hardware/emulator was/is responsible for:
- Taking a stream of data and presenting it; this included interpreting control sequences like "move cursor left", "blinking cursor", "clear-screen" although these control sequences were often different among manufacturers.
- Sending keycodes for keys typed by the user; most of these were standard ASCII characters, but some terminals sent propriety keycodes for even standard keys.
The 'tty' driver was responsible for:
- Managing the buffering, in raw or canonical mode; for example, buffering a line of characters until Enter is pressed.
- Managing the control flow; e.g. being able to stop/continue with Cntl-s/Cntl-q.
- Translating propriety keycodes to standard ASCII, where applicable.
- Intercepting certain control characters (like Cntl-c and Backspace) and processing them appropriately (send SIGINT on a Cntl-c or signal an EOF on Cntl-d.
- Canonical display of characters, for example, if
echo is turned off, then do not send feedback (character typed) back to the terminal.
The terminfo and termcap databases managed what terminal control characters should be sent for an operation (like 'clear-screen'). These control sequences were/are not interpreted by the driver, but by the hardware/emulator.
GNOME cannot interfere with Ctrl-Alt-F[N], since this is caught by the kernel, which implements VT switching. I.e., those key events never reach userspace, which is why you/your DE/any DE cannot override them or use them for some other purpose.
So if you can't switch VTs, there is a system level issue. In my first comment I said this sounds like panicing/busy looping, which it does. However, having that last 8 hours is pretty weird -- my next thought is it is I/O failure. Since you are using ubuntu 10.10, I presume this is an older netbook and the problem is new, even though you are still running the same old software. You also mention the problem has happened before but perhaps has been getting more serious, which again points to (disk) I/O failure -- your harddrive is dying. This creates a very nasty, unavoidable snag if the root filesystem is involved.
Unfortunately, you won't be able to tell for sure until you can look at the system logs. Right now, even if you had sshd running, I suspect you would not be able to get in because, again, it's the whole system that's frozen.
You can try shutting down and rebooting (moral of story: save work frequently, and save to some backup medium -- cloud, usb stick, whatever -- often as well). If it really is disk failure, you may be lucky to get anything off the disk. If you can reboot, the first thing you should do is:
cd /var; tar -cjf log
Then save /var/log.tar.bz2 to something so you can look at the logs on another computer, because (once again) if it is disk failure, this one is not going to be much good until you replace it. You may be able to duct-tape the problem by running e2fsck -cc (see man e2fsck) on the partitions, but that requires mounting the disk without the system on it running (e.g., if you can boot a liveCD from the external CD-ROM).
Best Answer
The
typescriptoutput captures all the characters sent to the pty. If you use for examplestty -opostto stop the terminal driver from doing its normal change of the newline character to CR+LF then you will see that you only have LF characters in the output.Hopefully helpful tip, use
to do a first pass at cleaning up the file.