Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to lounch command or bash script exit terminal and NOT interrupt command?

My solution was to run cron in specific time of day, but I'm sure there is something easier.

share|improve this question
    
Duplicate: How do I detach a process from Terminal, entirely? – slhck Jul 13 '12 at 12:19
up vote 22 down vote accepted

To avoid exit signals propagating to child processes of the terminal and shell, run the command with nohup, i.e.:

nohup cmd &
share|improve this answer
1  
This is the correct answer. Without nohup, the started process is still considered a "child" of the terminal process and thus terminated if the terminal is closed. – Izzy Jul 13 '12 at 13:04
2  
cmd & disown works too, since the & is treated like a ; command separator. The disown command removes the connection between the bash shell session and the backgrounded command. – lornix Jul 14 '12 at 20:34
    
zsh has a shorthand for this: cmd &|. – Thor Oct 26 '12 at 9:24

Put a "&" character after your command.

e.g:

/home/your/script.sh &
share|improve this answer
3  
in this case, when the terminal is closed, so is the process started by /home/your/script.sh -- as it was not detached from its "parent", but just "backgrounded". Use nohup to detach it for real. – Izzy Jul 13 '12 at 13:05
    
My bad, I didn't knew about that, but when I tested on my Debian, the command kept executing after closing the shell which launched it :/ – epingle Jul 13 '12 at 14:03
    
I'm not sure where exactly the backgrounded process is attached to and when. But if you e.g. log in to a remote machine, it is definitely stopped as soon as you log out (except if it daemonized itself). So to be 100% sure, you rather use nohup -- which also logs all (now invisible) output into a file called nohup.out located in the directory you started the command from. – Izzy Jul 13 '12 at 14:10
    
Okay, well thank you for your explanations ^^ – epingle Jul 13 '12 at 14:18

The SIGHUP signal is sent to the Process Group of the shell when the shell exits. The cleanest way is probably to tell Bash to run your process in it's parent process group, then any SIGHUP sent to the child pgid doesn't effect it.

 `-m'
       Job control is enabled (⇒Job Control).  All processes
       run in a separate process group.

E.g. Open a new terminal window.

$> echo $$
22170
$> sleep 555 &
$> ps -ef | grep "[s]leep 555"
AMD+ 17127 22170  0 11:12 pts/7    00:00:00 sleep 555
$> set -m && sleep 555 &
$> ps -ef | grep "[s]leep 555"
AMD+ 17127 22170  0 11:12 pts/7    00:00:00 sleep 555
AMD+ 17648 17647  0 11:13 pts/7    00:00:00 sleep 555

Now in a different terminal window:

$> kill -SIGHUP 22170
$> ps -ef | grep "[s]leep 555"
AMD+ 17648  3270  0 11:13 ?        00:00:00 sleep 555

As you can see our separate process gid saved our set -m'd process.

share|improve this answer

Using screen:

screen -S <session name> -d -m <your command>

after that you can quit the terminal, also you can reattach to it by:

screen -r <session name>

More info: reference

share|improve this answer

If you want to run a specific command or file every second or so in the background after exiting the terminal you could try this easy little thing;

nohup watch -n5 'bash script.sh' &

That would run scipt.sh every 5 seconds.

share|improve this answer
    
"nohup" is already covered by the accepted answer. And I'm pretty sure the asker mentioned cron because they were using it to say "Run this command a few seconds in the future", not to run it periodically. – David Richerby Aug 6 '15 at 21:01
    
My answer don't make things worse. Do see the point of down vote. Neural would be sufficient. – jamietelin Aug 6 '15 at 21:41

You must log in to answer this question.

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