1

I am trying to run a script in the background using '&' at the end of the command, but apparently, it isn't working out.

This is the issue I am facing. To use a paid simulation software, the provider has instructed me to run a certain script to enable license access. I am to leave this open and start the software from another terminal (in batch mode without GUI, since I am using a supercomputing cluster).

Trouble is, I can only send one script to the scheduler in the head node (which I am connected through ssh), and the job is forwarded to one of the compute nodes. So instead of starting a new terminal to run the software, I attempted to run the provided script in the background using '&'. This didn't work out. It appears the connection to the license server is getting closed as soon as it's started with this method.

./script1.sh &

Using 

xterm -e sh script1.sh

to open it in another terminal gave the following error-

xterm: Xt error: Can't open display: 

xterm: DISPLAY is not set

Any help would be greatly appreciated.

Improve this question

3 Answers 3

Reset to default
3

Sounds like the job you submit needs to be one which performs both tasks.

#!/bin/sh
license </dev/null >license.out 2>&1 &
license_pid=$!
simulator
kill $license_pid
wait $license_pid

This saves standard output and standard error from the licensing process to a file so you can tail that to see what it wants to tell you if there should be a problem.

Improve this answer
8
  • I have tried precisely this. It appears the process for running the license in the background is getting closed immediately. 'kill $license_pid' gave the error 'No such process'
    – Thariq Shanavas
    Commented Jul 12, 2017 at 16:50
  • Sometimes you can fix this by redirecting standard input to /dev/null.
    – Bob Eager
    Commented Jul 12, 2017 at 17:11
  • 'sh license_script.sh /dev/null 2>&1' Indeed did do the trick. Thanks @BobEager
    – Thariq Shanavas
    Commented Jul 12, 2017 at 17:34
  • That's standard output, which I was going to suggest next!
    – Bob Eager
    Commented Jul 12, 2017 at 17:42
  • 2
    Hi again, I finally ventured into what was inside the so-called license script. Turned out, at the heart of it, it was doing an ssh into another server. (I guess this was to be expected, after all). I modified the ssh line in the license script as per this answer (stackoverflow.com/a/5199505/7277918). I did not have to suppress the output to /dev/null or ignore the errors after this slight modification. Thanks again so much @tripleee, @Bob Eager!
    – Thariq Shanavas
    Commented Jul 13, 2017 at 16:55
2

Can you not ssh to the node, then start a copy of screen? Have a look at the manual page. It allows you to have two or more sessions as (effectively) subprocesses of your ssh login shell.

So, ssh as normal. Start screen. Type Ctrl-A followed by c to create a second screen. Start the license thing in that screen, then use Ctrl-A Ctrl-A to get back to the original screen. Start your application there. Use the Ctrl-A Ctrl-A sequence to switch back and forth if needed.

To detach without terminating, use Ctrl-ACtrl-d; to reattach later on (even after terminating your ssh session and logging back in, use screen -x.

Improve this answer
4
  • If things are running in batch on a node with no interactive terminal access, I don't think this will work.
    – tripleee
    Commented Jul 12, 2017 at 15:46
  • Yes, but he doesn't want to detach. He just needs two sessions on the same machine.
    – Bob Eager
    Commented Jul 12, 2017 at 16:15
  • Yes, I do not have interactive terminal access. Which is why I cannot use screen or similar alternatives which require Ctrl-A or other shortcuts. Thanks,
    – Thariq Shanavas
    Commented Jul 12, 2017 at 16:42
  • Ah, it wasn't entirely clear. Looks as if tripleee's answer is the one you want.
    – Bob Eager
    Commented Jul 12, 2017 at 17:10
0

(The question was posted by me, nearly three years ago. I dare say I've become better at shell scripting in the meantime - I ran across a similar problem recently and was reminded of this question once again.)

So as a previous comment suggested, all I had to use was screen. But since I did not have access to keyboard shortcuts as I was running the code on a cluster, I wasn't able to use Ctrl+A to get back to the body of my main script as the answer suggested.

Well, all I had to do was start screen in the background like this:

Start a screen with the name sample-screen in detached mode from the main script.

screen -S sample-screen -d -m

Ask the detached screen to run a comand without re-attaching it.

screen -S sample-screen -p 0 -X stuff "./script1.sh & ^M"

^M is the return character. Akin to pressing enter in the detached screen.

To kill the screen on exiting the script-

screen -XS sample-screen quit

Improve this answer

You must log in to answer this question.

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