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 ùse
fg to get back to the process so you can kill it e.g. with CTRL+C
Starting it as eithergunicorn -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. Runningnohup gunicorn -w 4 myapp:app &
will ensure the process to run even when you disconnect. Read the man page ofnohup`
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