views:

17092

answers:

10

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??

+27  A: 

Check out the "nohup" program.

JesperE
How do you stop it afterwards?
Derek Dahmer
Log in and do "kill <pid>". Use "pidof" if you don't know the pid.
JesperE
+43  A: 

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.

gpojd
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.
Adam Jaskiewicz
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.
Abyss Knight
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.
Adam Jaskiewicz
screen is definately on my top 3 too, truly awesome software.
Jonas Gulle
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.
Dave Sherohman
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.
Mark Renouf
yeah, screen is awesome, its like a non-gui vnc session :)
Aman Jain
+4  A: 

Use screen. It is very simple to use and works like vnc for terminals. http://www.bangmoney.org/presentations/screen.html

Deon
+8  A: 

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.
Robert Gamble
+2  A: 
nohup blah &

Substitute your process name for blah!

Brian Knoblauch
you might want to add redirect standard out and standard error.
David Nehme
That's a no-brainer, didn't think it needed to be spelled out... Guess I could be wrong though!
Brian Knoblauch
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.
Chas. Owens
+3  A: 

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.

Lochner Arendse
+2  A: 

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.

Contact me (firstname dot lastname at gmail dot com) if you want the source for daemonize.

Jonathan Leffler
Why don't you put the source on github or bitbucket?
Rob
Why does the absence of the source from github warrant a downvote?
Jonathan Leffler
Please ask questions about site rules elsewhere, this is not the place for discussion.
nailer
+3  A: 

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.

Dana the Sane
+4  A: 

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.

Will Hartung
A: 

Ive just used this to set up tshark. Works a treat. Thanks guys.