No. Well, at least not if you're running bash. The job will detach from your ssh session's PPID, and still be running on the server as your username.
–
JoeJul 1 '09 at 23:20

6

The instructions above will cause the process to exit when you close the shell. You additionally need to run the 'disown' command/builtin (this is in bash), which will disassociate the process from the shell and not send the HUP signal to the process on exit.
–
MarkJul 1 '09 at 23:25

On my version of bash [3.2.25(1)-release (i686-redhat-linux-gnu)], I tested the process, and didn't have to disown the job before disconnecting. The child PID disconnected from the parent PID, and kept running as my username without interruption. YMMV, I suppose.
–
JoeJul 1 '09 at 23:38

Note that retty (pasky.or.cz/~pasky/dev/retty) is a tool that can let you move a process running outside of screen into screen. It can be usefull to put you job in a screen if you forget. Then you can safely detach screen without any risk of the job to stop.
–
radiusJul 1 '09 at 22:45

If you are using bash, you can suspect with control-Z and background with bg.

Job control (from man bash)

If the operating system on which bash is running supports job
control, bash contains facilities to use it. Typing the
suspend character (typically ^Z, Control-Z) while a process
is running causes that process to be stopped and returns control
to bash. Typing the delayed suspend character (typically ^Y,
Control-Y) causes the process to be stopped when it
attempts to read input from the terminal, and control to be
returned to bash.

help bg

bg: bg [job_spec ...]
Place each JOB_SPEC in the background, as if it had been started with
`&'. If JOB_SPEC is not present, the shell's notion of the current
job is used.

Won't it be killed when I turn off my computer, thus severing the SSH session and killing the shell?
–
mikeJul 1 '09 at 22:25

Wait, are you running the command on your local computer and using SSH for some input/output? Or is this running on the remote computer? If the command is running on the remote computer, then you should be able to background it and disconnect.
–
ZoredacheJul 1 '09 at 22:28

If you know beforehand that you want to have it running in the background, the unix command at is a good option. It starts commands in the background at scheduled time, just like a cron job that does not repeat. Depending on your distribution, you might need to install it and to start the atd daemon.