6

I have a problem running Gaussian on remote Linux via SecureCRT on Windows.

Gaussian

Gaussian spawns different child executables ("link"s) when running. For example, I start Gaussian by running nohup g09 < test.in > test.out 2> test.out &, and g09 will spawns different links such as l301.exe and l502.exe at specific circumstances.

Run Gaussian

When I connect to the remote Linux box, and run Gaussian using nohup ${Path_Of_Gaussian}/g09 < jobname.in > jobname.out 2> jobname.out &:

  1. If I exit the shell by typing exit and press Enter, I can exit while Gaussian on Linux keeps running (name of the specific executable depends on specific timing).

  2. If I power down the computer (then the SecureCRT will be shutdown), Gaussian on Linux gets killed and complains "hang up".

  3. If I exit by typing exit and press Enter, and then log on, I can power down the computer and Gaussian on Linux keeps running.

  4. jlliagre's answer does not work in this case.

Run simple command

Taken a simple executable, which does nothing (i.e., deals nothing with input & output) but sleeps for 10 minutes, for example. When I run it by nohup ${Path_Of_Executable}/executable &:

  1. If I exit the shell by typing exit and press Enter, I can exit and the executable keeps running on Linux.

  2. If I power down the computer (then the SecureCRT will be shutdown), the executable running on Linux gets killed.

  3. If I exit by typing exit and press Enter, and then log on, I can power down the computer (then the SecureCRT will be shutdown) and the executable on Linux keeps running.

  4. As in jlliagre's knowledgeable answer, if I run nohup ${Path_Of_Executable}/executable </dev/null >/dev/null 2>&1 &, I can power down while the executable on Linux keeps running.

In other words, why would Gaussian, which is run on a remote machine with nohup, get killed when the local computer is powered down before the shell is exited?

Improve this question
4
  • What do you do with STDIN/STDOUT for the apps? Might want to try screen so the app always has a "terminal". Commented Nov 25, 2013 at 22:16
  • What about redirecting stderr, that is now stdout to /dev/null. Commented Nov 25, 2013 at 22:27
  • What shell and system are you using? Commented Nov 30, 2013 at 1:29
  • to help isolate this, install putty [chiark.greenend.org.uk/~sgtatham/putty/download.html] on windows and see if you get the same behavior. If you do, We need to troubleshoot the linux box. If The behavior is different you need to find out what secureCRT sends when you kill it. Commented Nov 30, 2013 at 7:04

2 Answers 2

Reset to default
4
+50

Idea #1 - disown

Based on the way you're describing your problem it sounds like Guassian still has some linkages to the shell that it was spawned from.

One additional thing you could try in addition to the nohup is to run disown -a as well, though this should do the same thing of disconnecting all the spawned processes from receiving SIGHUP.

Idea #2 - wrap it inside another Bash

Another thought would be to invoke Guassian like this.

  1. login to remote machine
  2. nohup bash
  3. run Guassian in this secondary shell

This might insulate Guassian from being terminated when the local machine loses the connection.

Idea #3 - use tmux or screen

I've run into applications similar to this as well, and rather than bang my head on the desk too much, I usually just reach for screen and/or tmux and run the application on the remote system inside Screen.

This protects the process better and has the added benefit of being able to reconnect with it later on.

Improve this answer
2
  • 1
    Thank you very much! The disown -a after the nohup command has helped ! Commented Dec 7, 2013 at 17:18
  • 1
    Thank you for the help... 8.5 years later! Commented Apr 16, 2022 at 20:00
2

This should better detach your application:

nohup ${PATH_OF_APPLICATION}/app </dev/null >/dev/null 2>&1 &

If this still doesn't work for some reason, try:

echo ${PATH_OF_APPLICATION}/app | at now
Improve this answer
6
  • @jilliagre: Thanks! Sorry that I just tried and still gets killed and complaints about hang up. Could you help to comment ? Commented Nov 26, 2013 at 1:11
  • @XichenLi That should not happen, especially with the at method. At this point I'd attach an strace to the program and see what's going on. Commented Nov 26, 2013 at 6:25
  • @Patrick I added the at suggestion after Xichen Li comment. Commented Nov 26, 2013 at 7:08
  • @jilliagre: Thanks! The at does not get the executable running at all. Do I need high privilege? I am a normal non-root. Commented Nov 26, 2013 at 13:04
  • @XichenLi at may not be installed standard apt-get or yum will probably install it for you. Commented Nov 30, 2013 at 6:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.