How to send process (application) to background if it always expects input on terminal and sending received data from uart to stdout all the time?

I cannot send my app to background with CTRL+Z & bg %number / bg %%.

Any idea, what is wrong?

My device (program) expects some input commands from terminal for configuration, before it is sent to background. And I'm getting error when try to send it to background.

# [CTRL-Z]
[1]+  Stopped                 sudo ./my_app

# bg %1

and it display me something like this:

[1]+  Stopped                 sudo ./my_app
  • What happens when you try? Doesn't Ctrl+Z send it to the background? What's the problem?
    – terdon
    Sep 17 '15 at 12:08
  • App stops, and after command bg %1 , it doesnt continue with execution in background.
    – Junior
    Sep 17 '15 at 12:09
  • What happens if you just run bg alone with no % 1?
    – terdon
    Sep 17 '15 at 12:10
  • it wont work, it just displays my jobs name [number] and that is stopped.
    – Junior
    Sep 17 '15 at 12:11
  • Huh? bg and bg %1 are equivalent, that's odd. In any case, if your program expects input from the terminal, how can it continue in the background? Please edit your question and add more detail, it's hard to understand what you mean.
    – terdon
    Sep 17 '15 at 12:12

When a program running in the background attempts to read from the terminal, it is stopped by a SIGTTIN signal. The input is currently going to the foreground process¹; it would be disruptive if input randomly went to the foreground program or the background program. So the background program is suspended until it's put in the foreground.

If you only need to pass data to your program at the beginning, pipe the data into it.

echo "config=foo" | ./my_app &

If you need to interact with the program now and then, but it can go on executing unattended most of the time, run it in a terminal multiplexer such as Screen or Tmux. For example, with screen:

screen -S my_app ./my_app

Type the necessary input, then press Ctrl+A to detach the screen session, i.e. let it run in the background and go back to the original terminal. When you want to interact with the program again, reattach to the screen session:

screen -S my_app -rd

If you need to perform some complex interactions automatically, write an expect script (or a script in another language with a similar library).

¹ Process group but I'm not going to go into that subtlety here.

  • So tell me, what happens to the foreground process if he doesn't find its controling terminal? @Gilles
    – Junior
    Sep 18 '15 at 7:12
  • 1
    @Junior If the controlling terminal goes away, the process receives a SIGHUP (conditions apply). Of course if it tries to read or write to a nonexistent terminal the operation will fail. Sep 18 '15 at 8:53

If your command continues to read from the tty, then you need to call


after you get a "stopped" message in order to type that expected input.


Shouldn't you pass the arguments to stdin, for it continue to work? If you just CTRL-Z it, it will wait for the input in the background.


$ cat test.sh

read var
echo $var

$ cat <<EOF > input

$ ./test.sh < input

$ ./test.sh <input > stdout 2> stderr &
[2] 23180
[2]-  Done                    ./test.sh < input > stdout 2> stderr

$ cat stdout

When trying to start it without passing the input:

$ ./test.sh > stdout 2> stderr &
[2] 13012

[2]+  Stopped                 ./test.sh > stdout 2> stderr
  • I just need to send those commands once, at system startup, not all the time.
    – Junior
    Sep 17 '15 at 12:23
  • Just have the file containing the input in the same place. At boot time, it should still be there and your program will read it as if it were a human manually inputting the arguments. I'm not sure I understand your particular case. Sep 17 '15 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.