1

While I was running apt upgrade I accidentally sent a Ctrl-S to that terminal window.

Now I know of XOFF, XON, Ctrl-Q, and something new about teletype.

When I sent a Ctrl-Q to the "paused" terminal, apt continued with its work.

From reading about XOFF, it is unclear to me what happened in apt, or what happens generally in any command which receives an XOFF. htop stops updating the display, which is something good to know, but is htop still running?

Was apt still running? Or was apt and htop effectively paused, frozen?

Apparently the processes can still receive input, while XOFF'd, so they are still executing.

What is happening? For example, the program counter, apparently it doesn't simply stop incrementing the program counter, freezing the program.

Does it depend on how the command is programmed to handle XOFF? Is there a general behavior that can be expected with the basic Linux commands?

Note that this and similar questions don't contain answers to my question since they don't mention what happens in the program itself. For example, I don't know if apt did continue to run silently, or if it was frozen/paused.

AdminBee
  • 22,803
Daniel F
  • 867

2 Answers2

4

As you may already know, XON and XOFF, bound to Ctrl+S and Ctrl+Q by default, are software flow control characters and in principle relics from the old times of paper-printing teletype terminals. They were used at times when a receiving equipment (often a paper printer) sometimes couldn't keep up with the input sent by a remote sender.

Nowadays, paper teletypes are no longer used, but the idea behind them is still retained in the software framework of a "terminal" (see e.g. here and this very nice article on the history of the TTY), which inherited and still implements some of the concepts used in the original paper-based terminals - one being the ability to interpret flow control characters.

Usually, a program running "on the console", i.e. connected to a pseudo-terminal, doesn't get to see the XON and XOFF characters as they are by default caught by the terminal, where the standard behaviour to XOFF is to stop printing the output it receives from the program. The program itself is otherwise unaffected and continues to run in the background, only the output is not "sent forward" to the user until an XON is received again.

If you write a program and want to explicitly receive these input characters, you can use the tcsetattr() system call in your program to disable the software flow control via the IXOFF flag (see here, e.g) - nano does that, for example.

AdminBee
  • 22,803
  • I'd say you are correct in probably the vast majority of cases. However, I believe that, depending on the scheduling policy, it ("program being unaffected") might not always be true. As I understand CFS, any thread running SCHED_RR or SCHED_FIFO and writing to some XOFFed tty is likely to be preempted and have to wait for the tty being XOFFed before getting a chance to be rescheduled. – MC68020 Sep 23 '20 at 12:30
  • @MC68020 Ok, that aspect I was not aware of. It probably doesn't contradict the statement of "otherwise unaffected" in the sense that the program itself doesn't receive a signal that would instruct it to perform special behaviour, but indirectly the execution of the program would then very much be affected. Feel free to edit, or supply another (more complete) answer. – AdminBee Sep 23 '20 at 12:33
1

htop stops updating the display, which is something good to know, but is htop still running [after Ctrl-S was entered]?

Yes, absolutely. htop or other command is NOT stopped or frozen by the Ctrl-S.

The IXON termios setting does not work like ISIG. Typing the VSTOP (Ctrl-S) or VSTART (Ctrl-Q) characters does NOT send any signal to the process running in the terminal.

It's very easy to check that; open two terminals: in the first enter

tail -f /tmp/file

and in the second

cat > /tmp/file

Now, in the second terminal type Ctrl-S, then keep blindly typing lines followed by Enter. They will appear on screen in the first terminal. If instead of cat it's a shell and those are commands like rm ..., they will be run without having to be echoed back on the screen.

what happens generally in any command which receives an XOFF.

The command does not "receive an XOFF". It's all handled inside the terminal driver. From the point of view of the application, nothing happens. If the program keeps sending copious output (or the ECHO termios setting is on --the default-- and it keeps receiving copious input) any write (or respective read) to the terminal will at some point block until the Ctrl-Q is received.