Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
@jasonwryan Thank you! –  Xichen Li Nov 25 '13 at 22:06
    
What do you do with STDIN/STDOUT for the apps? Might want to try screen so the app always has a "terminal". –  rickhg12hs Nov 25 '13 at 22:16
    
What about redirecting stderr, that is now stdout to /dev/null. –  richard Nov 25 '13 at 22:27
    
What shell and system are you using? –  psusi Nov 30 '13 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. –  hildred Nov 30 '13 at 7:04
add comment

2 Answers 2

up vote 3 down vote accepted
+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.

share|improve this answer
    
Thank you very much! The disown -a after the nohup command has helped ! –  Xichen Li Dec 7 '13 at 17:18
add comment

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
share|improve this answer
    
@jilliagre: Thanks! Sorry that I just tried and still gets killed and complaints about hang up. Could you help to comment ? –  Xichen Li Nov 26 '13 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. –  Patrick Nov 26 '13 at 6:25
    
@Patrick I added the at suggestion after Xichen Li comment. –  jlliagre Nov 26 '13 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. –  Xichen Li Nov 26 '13 at 13:04
    
@XichenLi at may not be installed standard apt-get or yum will probably install it for you. –  hildred Nov 30 '13 at 6:59
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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