By GetFree

2008-11-12 19:19:54 8 Comments

I'm working on a Linux machine through SSH (Putty). I need to leave a process running during the night, so I thought I could do that by starting the process in background (with an ampersand at the end of the command) and redirecting stdout to a file.

To my surprise, that doesn't work. As soon as I close the Putty window, the process is stopped.

How can I prevent that from happening??


@Eugene Shatsky 2017-12-26 17:10:28

On systemd/Linux, systemd-run is a nice tool to launch session-independent processes.

@anthonyrisinger 2012-03-10 12:01:44

daemonize? nohup? SCREEN? (tmux ftw, screen is junk ;-)

Just do what every other app has done since the beginning -- double fork.

# ((exec sleep 30)&)
# grep PPid /proc/`pgrep sleep`/status
PPid:   1
# jobs
# disown
bash: disown: current: no such job

Bang! Done :-) I've used this countless times on all types of apps and many old machines. You can combine with redirects and whatnot to open a private channel between you and the process.

Create as



run_in_coproc () {
    echo "coproc[$1] -> main"
    read -r; echo $REPLY

# dynamic-coprocess-generator. nice.
_coproc () {
    local i o e n=${1//[^A-Za-z0-9_]}; shift
    exec {i}<> <(:) {o}<> >(:) {e}<> >(:)
. /dev/stdin <<COPROC "${@}"
    (("\[email protected]")&) <&$i >&$o 2>&$e
    $n=( $o $i $e )

# pi-rads-of-awesome?
for x in {0..5}; do
    _coproc COPROC$x run_in_coproc $x
    declare -p COPROC$x

for x in COPROC{0..5}; do
. /dev/stdin <<RUN
    read -r -u \${$x[0]}; echo \$REPLY
    echo "$x <- main" >&\${$x[1]}
    read -r -u \${$x[0]}; echo \$REPLY

and then

# ./ 
declare -a COPROC0='([0]="21" [1]="16" [2]="23")'
declare -a COPROC1='([0]="24" [1]="19" [2]="26")'
declare -a COPROC2='([0]="27" [1]="22" [2]="29")'
declare -a COPROC3='([0]="30" [1]="25" [2]="32")'
declare -a COPROC4='([0]="33" [1]="28" [2]="35")'
declare -a COPROC5='([0]="36" [1]="31" [2]="38")'
coproc[0] -> main
COPROC0 <- main
coproc[1] -> main
COPROC1 <- main
coproc[2] -> main
COPROC2 <- main
coproc[3] -> main
COPROC3 <- main
coproc[4] -> main
COPROC4 <- main
coproc[5] -> main
COPROC5 <- main

And there you go, spawn whatever. the <(:) opens an anonymous pipe via process substitution, which dies, but the pipe sticks around because you have a handle to it. I usually do a sleep 1 instead of : because its slightly racy, and I'd get a "file busy" error -- never happens if a real command is ran (eg, command true)

"heredoc sourcing":

. /dev/stdin <<EOF

This works on every single shell I've ever tried, including busybox/etc (initramfs). I've never seen it done before, I independently discovered it while prodding, who knew source could accept args? But it often serves as a much more manageable form of eval, if there is such a thing.

@anthonyrisinger 2012-03-10 20:56:12

why the down vote ... so what if the question is old; it's obviously relevant considering there are 11 other answers that suck. this solutions is, sans systemd, the idiomatic and accepted way to daemonize for the last 30 years, not pointless apps, eg. nohup et al.

@Alex D 2013-01-17 14:06:52

no matter how good your answer is, sometimes somebody on SO won't like it and will downvote. It's better not to worry about it too much.

@tbc0 2013-08-14 15:46:25

This technique doesn't work when trying to start a job programmatically via ssh, e.g. '$ ssh myhost "((exec sleep 30)&)"'

@anthonyrisinger 2013-10-08 18:40:46

@tbc0 sure it does; Ctrl^C the ssh client after it hangs then login to the machine... you will find the sleep 30 command is still running. i'm not sure off-hand why ssh does not release (though i'd guess the sleep process still holds a ref to ssh's pty or similar) but regardless, the sleep command is unaffected by any signals sent (such as the Ctrl^C) and will persist after ssh closes.

@anthonyrisinger 2013-10-08 18:45:51

@tbc0 ...try ssh myhost "((exec sleep 500)&) >/dev/null"

@tbc0 2013-10-11 06:09:29

@anthonyrisinger ok, that works. I think this is cleaner: ssh myhost 'sleep 500 >&- 2>&- <&- &' TMTOWTDI ;)

@Hamy 2016-12-19 13:18:09

This is great. the only solution that actually works in busybox. it deserves more upvotes

@Jonathan Leffler 2008-11-12 19:50:05

As others have noted, to run a process in the background so that you can disconnect from your SSH session, you need to have the background process properly disassociate itself from its controlling terminal - which is the pseudo-tty that the SSH session uses.

You can find information about daemonizing processes in books such as Stevens' "Advanced Network Program, Vol 1, 3rd Edn" or Rochkind's "Advanced Unix Programming".

I recently (in the last couple of years) had to deal with a recalcitrant program that did not daemonize itself properly. I ended up dealing with that by creating a generic daemonizing program - similar to nohup but with more controls available.

Usage: daemonize [-abchptxV][-d dir][-e err][-i in][-o out][-s sigs][-k fds][-m umask] -- command [args...]
  -V          print version and exit
  -a          output files in append mode (O_APPEND)
  -b          both output and error go to output file
  -c          create output files (O_CREAT)
  -d dir      change to given directory
  -e file     error file (standard error - /dev/null)
  -h          print help and exit
  -i file     input file (standard input - /dev/null)
  -k fd-list  keep file descriptors listed open
  -m umask    set umask (octal)
  -o file     output file (standard output - /dev/null)
  -s sig-list ignore signal numbers
  -t          truncate output files (O_TRUNC)
  -p          print daemon PID on original stdout
  -x          output files must be new (O_EXCL)

The double-dash is optional on systems not using the GNU getopt() function; it is necessary (or you have to specify POSIXLY_CORRECT in the environment) on Linux etc. Since double-dash works everywhere, it is best to use it.

You can still contact me (firstname dot lastname at gmail dot com) if you want the source for daemonize.

However, the code is now (finally) available on GitHub in my SOQ (Stack Overflow Questions) repository as file daemonize-1.10.tgz in the packages sub-directory.

@Rob 2009-09-14 08:55:29

Why don't you put the source on github or bitbucket?

@Jonathan Leffler 2009-09-14 09:06:49

Why does the absence of the source from github warrant a downvote?

@DepressedDaniel 2017-02-20 07:28:15

@JonathanLeffler IMHO listing all the cool options of a program that is not publicly available in any form (not even commercially) borders on wasting the reader's time.

@haccks 2017-02-06 08:59:04

Accepted answer suggest using nohup. I would rather suggest using pm2. Using pm2 over nohup has many advantages, like keeping the application alive, maintain log files for application and lot more other features. For more detail check this out.

To install pm2 you need to download npm. For Debian based system

sudo apt-get install npm

and for Redhat

sudo yum install npm

Or you can follow these instruction. After installing npm use it to install pm2

npm install [email protected] -g

Once its done you can start your application by

$ pm2 start app.js              # Start, Daemonize and auto-restart application (Node)
$ pm2 start              # Start, Daemonize and auto-restart application (Python)

For process monitoring use following commands:

$ pm2 list                      # List all processes started with PM2
$ pm2 monit                     # Display memory and cpu usage of each app
$ pm2 show [app-name]           # Show all informations about application

Manage processes using either app name or process id or manage all processes together:

$ pm2 stop     <app_name|id|'all'|json_conf>
$ pm2 restart  <app_name|id|'all'|json_conf>
$ pm2 delete   <app_name|id|'all'|json_conf>

Log files can be found in

$HOME/.pm2/logs #contain all applications logs

Binary executable files can also be run using pm2. You have to made a change into the jason file. Change the "exec_interpreter" : "node", to "exec_interpreter" : "none". (see the attributes section).

#include <stdio.h>
#include <unistd.h>  //No standard C library
int main(void)
    printf("Hello World\n");
    sleep (100);
    printf("Hello World\n");

    return 0;

Compiling above code

gcc -o hello hello.c  

and run it with np2 in the background

pm2 start ./hello

@GetFree 2017-02-06 10:37:17

Can this be used to run binary executables?

@haccks 2017-02-06 10:57:47

@GetFree; Yes. You can.

@GetFree 2017-02-06 11:12:29

Add an example please. The answer as it is right now looks like it's good only for script files.

@haccks 2017-02-06 11:30:46

@GetFree; Added the example. Let me know if you have any problem.

@jcodeninja 2008-11-12 19:35:15

Nohup allows a client process to not be killed if a the parent process is killed, for argument when you logout. Even better still use:

nohup /bin/sh -c "echo \$\$ > $pidfile; exec $FOO_BIN $FOO_CONFIG  " > /dev/null

Nohup makes the process you start immune to termination which your SSH session and its child processes are kill upon you logging out. The command i gave provides you with a way you can store the pid of the application in a pid file so that you can correcly kill it later and allows the process to run after you have logged out.

@RAM 2016-07-03 00:59:11

For most processes you can pseudo-daemonize using this old Linux command-line trick:

# ((mycommand &)&)

For example:

# ((sleep 30 &)&)
# exit

Then start a new terminal window and:

# ps aux | grep sleep

Will show that sleep 30 is still running.

What you have done is started the process as a child of a child, and when you exit, the nohup command that would normally trigger the process to exit doesn't cascade down to the grand-child, leaving it as an orphan process, still running.

I prefer this "set it and forget it" approach, no need to deal with nohup, screen, tmux, I/o redirection, or any of that stuff.

@Adeel Ahmad 2014-03-05 05:28:07

nohup is very good if you want to log your details to a file. But when it goes to background you are unable to give it a password if your scripts ask for. I think you must try screen. its a utility you can install on your linux distribution using yum for example on CentOS yum install screen then access your server via putty or another software, in your shell type screen. It will open screen[0] in putty. Do your work. You can create more screen[1], screen[2], etc in same putty session.

Basic commands you need to know:

To start screen


To create next screen


To move to next screen you created


To detach


During work close your putty. And next time when you login via putty type

screen -r

To reconnect to your screen, and you can see your process still running on screen. And to exit the screen type #exit.

For more details see man screen.

@tymik 2016-05-26 18:01:52

assuming that yum is the right tool, when you don't know the distro, is not good. you should make it clear on which distros screen can be installed with yum.

@Shravan Ramamurthy 2015-11-12 05:02:58

I used screen command. This link has detail as to how to do this

@Max 2014-04-25 23:30:46

On a Debian-based system (on the remote machine) Install:

sudo apt-get install tmux



run commands you want

To rename session:

Ctrl+B then $

set Name

To exit session:

Ctrl+B then D

(this leaves the tmux session). Then, you can log out of SSH.

When you need to come back/check on it again, start up SSH, and enter

tmux attach session_name

It will take you back to your tmux session.

@kilgoretrout 2018-10-25 05:15:02

this is the way to go

@tbc0 2013-08-14 15:51:50

Append this string to your command: >&- 2>&- <&- &. >&- means close stdout. 2>&- means close stderr. <&- means close stdin. & means run in the background. This works to programmatically start a job via ssh, too:

$ ssh myhost 'sleep 30 >&- 2>&- <&- &'
# ssh returns right away, and your sleep job is running remotely

@janv 2012-06-16 16:13:26

There's also the daemon command of the open-source libslack package.

daemon is quite configurable and does care about all the tedious daemon stuff such as automatic restart, logging or pidfile handling.

@THESorcerer 2012-05-30 09:23:05

i would also go for screen program (i know that some1 else answer was screen but this is a completion)

not only the fact that &, ctrl+z bg disown, nohup, etc. may give you a nasty surprise that when you logoff job will still be killed (i dunno why, but it did happened to me, and it didn't bother with it be cause i switched to use screen, but i guess anthonyrisinger solution as double forking would solve that), also screen have a major advantage over just back-grounding:

screen will background your process without losing interactive control to it

and btw, this is a question i would never ask in the first place :) ... i use screen from my beginning of doing anything in any unix ... i (almost) NEVER work in a unix/linux shell without starting screen first ... and i should stop now, or i'll start an endless presentation of what good screen is and what can do for ya ... look it up by yourself, it is worth it ;)

@THESorcerer 2012-05-30 09:25:29

PS anthonyrisinger, you are good, i give you that but ... 30 years ? i bet that is a solution when &, bg, nohup or screen was not there yet, and no offense i appreciate your knowledge but that is far too complicated to use it :)

@anthonyrisinger 2012-09-24 04:08:52

(aside: see Tmux) although this vastly predates me [1987], & (asynchronous execution) was introduced by the Thompson shell in 1971, for the first version of UNIX ... so it literally "has always been" ;-) alas, I was too conservative -- it's actually been 41 years.

@Alexey Shurygin 2011-11-15 00:17:53

If you're willing to run X applications as well - use xpra together with "screen".

@Brian Knoblauch 2008-11-12 19:31:35

nohup blah &

Substitute your process name for blah!

@David Nehme 2008-11-12 19:34:15

you might want to add redirect standard out and standard error.

@Chas. Owens 2009-04-21 14:51:36

nohup redirects stdout and stderr to nohup.out (or nohup.out and nohup.err depending on the version), so unless you are running multiple commands it is not necessary.

@Will Hartung 2008-11-12 19:53:57

Personally, I like the 'batch' command.

$ batch
> mycommand -x arg1 -y arg2 -z arg3
> ^D

This stuffs it in to the background, and then mails the results to you. It's a part of cron.

@Dana the Sane 2008-11-12 19:53:08

If you use screen to run a process as root, beware of the possibility of privilege elevation attacks. If your own account gets compromised somehow, there will be a direct way to take over the entire server.

If this process needs to be run regularly and you have sufficient access on the server, a better option would be to use cron the run the job. You could also use init.d (the super daemon) to start your process in the background, and it can terminate as soon as it's done.

@Robert Gamble 2008-11-12 19:27:26

When the session is closed the process receives the SIGHUP signal which it is apparently not catching. You can use the nohup command when launching the process or the bash built-in command disown -h after starting the process to prevent this from happening:

> help disown
disown: disown [-h] [-ar] [jobspec ...]
     By default, removes each JOBSPEC argument from the table of active jobs.
    If the -h option is given, the job is not removed from the table, but is
    marked so that SIGHUP is not sent to the job if the shell receives a
    SIGHUP.  The -a option, when JOBSPEC is not supplied, means to remove all
    jobs from the job table; the -r option means to remove only running jobs.

@Christian K. 2012-07-18 22:49:16

Advantage here is that disown works for processes which have already been started.

@Stewart 2013-06-27 13:03:02

Does 'jobspec' mean the pid?

@Stewart 2013-06-27 13:04:07

No worries, found this answer here…

@Deon 2008-11-12 19:23:01

Use screen. It is very simple to use and works like vnc for terminals.

@gpojd 2008-11-12 19:22:00

I would recommend using GNU Screen. It allows you to disconnect from the server while all of your processes continue to run. I don't know how I lived without it before I knew it existed.

@Adam Jaskiewicz 2008-11-12 20:02:40

This is one of the greatest pieces of software I've ever used. Seriously. I have it running on a BSD box that I ssh into from EVERYWHERE, and can simply re-attach to my screen and have all of my terminals where I'm doing all sorts of stuff.

@willasaywhat 2008-11-12 21:06:48

I can attest to this one. Screen is a great application. The ability to re-attach is amazing, and saves a lot of potentially lost work.

@Adam Jaskiewicz 2008-11-12 21:11:54

I even use it on local machines, and attach multiple xterms to the same screen session (screen -x). That way I can open up many windows within my screen session, and freely switch my various xterms from window-to-window.

@Jonas Gulle 2008-11-12 21:39:22

screen is definately on my top 3 too, truly awesome software.

@Dave Sherohman 2008-11-13 00:36:33

Depends on whether you need to reconnect to the backgrounded app or not. If you do, then, yeah, screen is the only way to fly. If it's fire-and-forget, though, then nohup fits the bill just as nicely, if not better.

@Mark Renouf 2009-04-21 14:47:54

There is also 'dtach' which implements only screen's detach mechanism, however it's a bit harder to use but gives control over the socket file that gets created for a detached process. I would recommend using dtach if this were a non-interactive scripted process that needed to remotely launch processes. Otherwise just use screen, it's easier.

@Aman Jain 2010-01-14 02:44:57

yeah, screen is awesome, its like a non-gui vnc session :)

@gerlos 2014-02-27 19:07:21

+1 for screen. Or, as an alternative, tmux (I like this one more than screen) or even byobu, which is a nice frontend for screen or tmux. You can just type screen to get a shell to use and return later at any time, or run your command with screen, like "screen command": the screen session will exist as long as the process "command" exist, and if it's something very long, you can go back and look at its standard output at any time.

@mabalenk 2017-03-03 16:03:21

Linode website offers a good introduction on how to use screen.

@JesperE 2008-11-12 19:21:30

Check out the "nohup" program.

@Derek Dahmer 2010-07-13 17:49:12

How do you stop it afterwards?

@JesperE 2010-07-13 18:01:22

Log in and do "kill <pid>". Use "pidof" if you don't know the pid.

@KCD 2013-04-01 23:03:28

You can use nohup command > /dev/null 2>&1 & to run in the background without creating any stdout or stderr output (no nohup.out file)

@Sergey 2013-12-28 06:29:53

What if I need to provide some input? For example, I have a long-running script that I need to run in the background but it first asks for my FTP password. nohup doesn't help in this case. Is there a way to fiddle with Ctrl+Z / bg?

@Anomaly 2015-10-31 22:20:16

Since I'm lazy and bad at memorizing cryptic sequences of characters, I wrote this, based on what @KCD said, and have been using it a lot.

@Tino 2017-02-28 08:25:26

This does not work at my side as this does not shield the program from getting SIGHUP when the ctty is closed. I have a program which must not receive SIGHUP, ever. nohup does not work, as it does not prevent SIGHUP, it just defaults to ignore it, which need not prevail. As I do not have screen nor tmux nor at nor similar, I need a way on shell level to disassociate a program from the ctty for sure. The only way I found was a hack to start the program with ssh -T remote '(program&)&' which makes it impossible to background the program in an interactive ssh session.

Related Questions

Sponsored Content

30 Answered Questions

[SOLVED] How to kill a process running on particular port in Linux?

4 Answered Questions

[SOLVED] Use SSH to start a background process on a remote server, and exit session

6 Answered Questions

[SOLVED] Background process in linux

26 Answered Questions

[SOLVED] How do I run a node.js app as a background service?

14 Answered Questions

[SOLVED] How to run Node.js as a background process and never die?

7 Answered Questions

[SOLVED] How to get process ID of background process?

3 Answered Questions

[SOLVED] Windows ssh - How to keep proccess running after Disconnect

14 Answered Questions

[SOLVED] What killed my process and why?

2 Answered Questions

[SOLVED] vagrant ssh -c and keeping a background process running after connection closed

  • 2014-08-15 18:08:26
  • prentice
  • 2588 View
  • 4 Score
  • 2 Answer
  • Tags:   linux vagrant

Sponsored Content