12

I am seeing some strange behavior on my RHEL6 bash prompt. I often like to execute command lines that look like ...

$ ./myscript > junk 2>&1

... then hit Ctrl-Z and then execute ...

$ bg
$ tail -f junk
blah blah blah blah
blah blah blah blah

But today for some reason I am see that my job stays "stopped" and is not "running".

$ uname -a
Linux myhost 2.6.18-371.11.1.el5 #1 SMP Mon Jun 30 04:51:39 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
$ ./myscript.sh > output-07-JUL-16.txt 2>&1
^Z
[1]+  Stopped                 ./myscript.sh > output-07-JUL-16.txt 2>&1
$ bg
[1]+ ./myscript.sh > output-07-JUL-16.txt 2>&1 &
$ jobs
[1]+  Stopped                 ./myscript.sh > output-07-JUL-16.txt 2>&1
$ jobs
[1]+  Stopped                 ./myscript.sh > output-07-JUL-16.txt 2>&1

The script I am running is nothing exotic ...

#!/bin/sh

count=`wc -l hostlist`
total=1
for i in `grep -v "^#" hostlist`
do
    echo "Doing $total or $count $i"
    sudo scp -q access.sh $i:/tmp
    sudo ssh -q $i /tmp/access.sh
    sleep 1
    total=`expr $total + 1`
done
thanasisp
  • 7,802
  • 2
  • 26
  • 39
Red Cricket
  • 2,183
  • 6
  • 25
  • 37
  • 5
    See if giving `ssh` a `-n` option helps. Without that, it will try to read from stdin, and if that happens in a background job, it usually gets stopped (it gets a SIGTTIN signal). – Mark Plotnick Jul 07 '16 at 17:25
  • `sudo` has a time limit. Wonder if that could be an issue. Did you run the script using sudo? – unxnut Jul 07 '16 at 17:31
  • Thanks Mark Plotnick! That did the trick. Please post your comment as an answer. – Red Cricket Jul 07 '16 at 17:45

1 Answers1

21
$ bg
[1]+ ./myscript.sh > output-07-JUL-16.txt 2>&1 &
$ jobs
[1]+  Stopped                 ./myscript.sh > output-07-JUL-16.txt 2>&1

Running jobs -l will show more detail about your background jobs. In the case of your shell script, it will display something like the following, which reveals the reason why the job stopped:

[1]+  4274 Stopped (tty input)     ./myscript.sh > output-07-JUL-16.txt 2>&1

Something in your script is trying to read from the terminal. When a background job tries to read from its controlling terminal, it gets a SIGTTIN signal and stops. (Only the foreground job can read from the controlling terminal.)

The cause: in your script, you have

sudo ssh -q $i /tmp/access.sh

ssh by default will try to read from its stdin. You can give ssh the -n option to tell it not to read from stdin.

sudo ssh -n -q $i /tmp/access.sh
Mark Plotnick
  • 24,913
  • 2
  • 59
  • 81
  • 1
    I upvoted this very informative answer as I learned that `jobs -l` does more than simply “lists process IDs in addition to the normal information”. I had similar issues running X11 applications on a remote host in the background so using the `-n` option (or the recommded`-f` option which implies `-n`) solved those issues. – Anthony Geoghegan Jun 05 '19 at 16:12
  • In my case the program was Synopsys DVE started in gui mode. Using `nohup`, e.g. `nohup simv -gui` instead of `simv -gui` fixed my `Stopped (tty input)` problem. – Axel Bregnsbo May 03 '20 at 12:24