I use Linux terminal in Ubuntu.

When I write seq 100 1 | less & to run it it in the background, it just stops.

I used other ways to run it on background too, like using bg [jobnr] but it just stops.

I find the job number, and write bg 1 (when it's 1), but then I check the process and it's not running.

The same happens with man pi too or other "man pages".

But pi 10000000 can run on background, and when it's finished it just prints the pi-number on terminal.

It was an assignment to see if less can be run on background, and why it can't be run on background. After search online I didn't find much information about why.

Why does some processes can't be run in the background but others can do run despite both printing on terminal?

  • Why do you want to run less (or man) in the background?
    – Kusalananda
    Commented Sep 17, 2020 at 13:04
  • @Kusalananda It was an assignment to test if less can be run on background, and why it can't be run on background. After search online I didn't find much information.
    – Coder88
    Commented Sep 17, 2020 at 13:34
  • some things to look at: less takes input from the terminal (I think it takes input from stdout). Commented Sep 17, 2020 at 22:09

2 Answers 2


less cannot run in the background because it's trying to interact with the controlling terminal, which cause it to be forcefully stopped. Only a foreground process can read from the terminal or change the terminal settings.

When a background process tries to change the terminal settings, it gets a SIGTTOU signal. When it tries to read from the terminal, it gets a SIGTTIN signal. Both signals cause it to stop. If a process goes on and ignores those signals, the operations which caused them may fail, so this is not a way out of this (e.g. a read from the terminal will fail with an EIO error).


less is peculiar by the fact that in order to be able to be used as command | less, it opens the controlling terminal directly via /dev/tty instead of assuming that the controlling terminal is its stdin or stderr, as other interactive programs like most editors or shells do.

You can configure your terminal with stty tostop so that background programs which try to write to the controlling terminal will be stopped too, but that's not the default anywhere, and not very practical.


Because it needs to access the terminal.

If a process is run in the background, all the terminal input is going to the process that runs in the foreground, most likely the shell. If a background process would just pick a character whenever it wants to read, that would interfere with your normal, foreground, work. To see where that could lead to, consider what happens if your background process could just read the terminal in between.

Process1: important data(bg)    you type      Process2: just a quiz-game (fg)
output                                        output
Do you want to quit(q) or                     How do you call a group of 5 
   continue (c)                                     music players?
                          <-      q

OK, quit, save data?              u     ->
                                  i     ->
                          <-      n
                                  t     -> 
Ok destroyed all data.            e     ->
                                  t     ->
                                 <enter>->           Wrong answer: uitet.

You can, as an example to see how that works, use the following script:


while read sentence ; do
        echo "$sentence"
        echo '----------------'
        head -1 /dev/tty

The normal read reads input from STDIN. You can redirect anything to it. The head -1 /dev/tty will force input from the terminal. If you run in the foreground, the script will give you a line for every enter that you give.

If you run this script in the background, cat tst.sh | bash tst.sh &, it will stop at the point where you explicitly require input from the terminal.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .