5

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 ^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
  • 4
    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 7 '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 7 '16 at 17:31
  • Thanks Mark Plotnick! That did the trick. Please post your comment as an answer. – Red Cricket Jul 7 '16 at 17:45
6
$ bg
[1]+ ./myscript.sh > output-07-JUL-16.txt 2>&1 &
$ jobs
[1]+  Stopped                 ./myscript.sh > output-07-JUL-16.txt 2>&1

If you run jobs -l, you might see something like the following, which makes it clear why the job has 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
  • 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 5 at 16:12

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.