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

Context: This is a very basic question

Using Putty and SSH for the first time to do some serious server setup and run into the situation where I have started a process that I do not want to stop.

The process is the gunicorn WSGI HTTP Server (running on Centos 6.3).

The command I used to start the process is (as per their Quick Start):

gunicorn -w 4 myapp:app

At this point in the work session, I have lost the command prompt. This must be such a non-issue that it doesn't even enter into an experienced user's consciousness. But unfortunately at my level of experience, I am left with several fundamental questions:

  • Does the fact that I have lost the command prompt mean that the process is still running?
  • How do I get back to the command prompt without killing the process?
  • How do I come back and monitor the process later?
  • How do I eventually kill the process?

Any help is appreciated, thanks so much!

enter image description here

share|improve this question

migrated from stackoverflow.com Oct 13 '12 at 1:48

This question came from our site for professional and enthusiast programmers.

up vote 2 down vote accepted

You could use

nohup gunicorn -w 4 myapp:app &> /dev/null &

This will

  • execute gunicorn -w 4
  • send the process to background - that's the & at the end. You can view background jobs via jobs and bring them to foreground via fg $id if they e.g. wait for interaction
  • mute the process by redirecting standard error and standard output to /dev/null, so it won't show in your shell &> /dev/null
  • make sure that the process will not be killed if the parent (here your shell) ends. nohup


EDIT:

To monitor the program as whole it would be fine to monitor output of the program.

So we can modify the command in this manner:

  • duplicate standard error output to standard output stream 2>&1. More on this construction can be found here: What does “2>&1” do in command line?
  • redirect standard output stream to our file >~/gunicorn.log

The final command will look like this:

nohup gunicorn -w 4 myapp:app 2>&1 >~/gunicorn.log &


To kill the process you could fire series of these commands:

ps aux | grep gunicorn

then identify the PID (I would refer to it as $PID) of the gunicorn process and stop it gracefully:

kill $PID

or stop it forcefully:

kill -9 $PID


You could customize it to your further needs.

share|improve this answer

Does the fact that I have lost the command prompt mean that the process is still running?

Unlikely. The process will have a connection to the virtual terminal of ssh, which will eventually time out and kill all the processes associated with that terminal - though gunicorn could be written in a manner that it doesn't exit when the controlling terminal disappears.

How do I get back to the command prompt without killing the process?

If the terminal is still alive, hit CTRL+Z to get back to the command prompt, then write bg to place gnuicorn in the background (and use fg to get back to the process so you can kill it - e.g. with CTRL+C).

Starting it as either gunicorn -w 4 myapp:app & will place the process in the background of the shell immediately - though depending on the server it might still get killed when your ssh session ends. Running nohup gunicorn -w 4 myapp:app & will ensure the process to run even when you disconnect. Read the man page of nohup

Another option is to run the process in a terminal that allows you to reattach to it. That's what the GNU screen or the tmux allows you to do - effectivly allowing you to disconnect the ssh session, connect back later on and reattach to an existing terminal session.

How do I come back and monitor the process later?

You can't, unless you run the process inside a GNU screen or tmux session - in which case the docs/tutorials for screen or tmux will tell you the detail - or you've started the server to run as a service/in the background.

How do I eventually kill the process?

Most server programs will have a managment interface (e.g. commands you'll have to run), and you'll have to find the relevant information in the documentation.

Or they integrate themselves in the linux/unix startup and service management procedures, in which case you manage them as any other services , e.g. /sbin/service fooserver start /sbin/service fooserver stop on some linux distros.

Or you have to do it manually. Find the process by running ps -ef |grep fooserver to find its pid, and kill it, kill <the pid>. Or look in the documentation if the erver can write a "pid file" when it starts up, so you can find the process id in that file later on.

Now, it seems at least gunicorn has a -D argument, which is used to place the server in the background, disconnecting it from the terminal, so it doesn't get killed when your ssh/putty connection disconnects. See http://gunicorn.org/configure.html#server-mechanics

You'll then have to manage/monitor it manually, i.e. kill it as I mentioned above, monitor it through the log file it produces - or any integrated monitoring webapp or commands gnuicorn might have.

The intent here is clearly for someone to package gnuicorn for a particular linux/*nix variant, and write the relevant scripts and config files to integrate it into the native service management of the distro. (e.g. a standard script under /etc/init.d/ to start and stop the server, used on many linux'es)

share|improve this answer

1) Yes, the process is running.

2) You can start the process in the background by starting it as

gunicorn -w 4 myapp:app &

3) You can find the process ID (pid) with

ps aux | grep gunicorn

4) To kill the process, you can kill it with

kill (the pid you found in 3)

To force the process to stop, run

kill -9 (the pid you found in 3)
share|improve this answer

Read up on nohup(1) command for starting background processes and being able to disconnect your terminal session.

share|improve this answer

Going forward, you may find the gnu screen are quite helpful while working on a terminal like putty.Or even the better alternative for gnu screen -- tmux, which gets more and more popular now due to its powerful, consistent, well-documented command interfaces.

share|improve this answer

You must log in to answer this question.

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