Can I nohup/screen an already-started process?

If you're using Bash, you can run disown -h job

disown

disown [-ar] [-h] [jobspec ...]

Without options, each jobspec is removed 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. If jobspec is not present, and neither the -a nor -r option is supplied, the current job is used. If no jobspec is supplied, the -a option means to remove or mark all jobs; the -r option without a jobspec argument restricts operation to running jobs.

Use reptyr

From the README:

reptyr - A tool for "re-ptying" programs.
-----------------------------------------

reptyr is a utility for taking an existing running program and
attaching it to a new terminal. Started a long-running process over
ssh, but have to leave and don't want to interrupt it? Just start a
screen, use reptyr to grab it, and then kill the ssh session and head
on home.

USAGE
-----

  reptyr PID

"reptyr PID" will grab the process with id PID and attach it to your
current terminal.

After attaching, the process will take input from and write output to
the new terminal, including ^C and ^Z. (Unfortunately, if you
background it, you will still have to run "bg" or "fg" in the old
terminal. This is likely impossible to fix in a reasonable way without
patching your shell.)

A few blog posts by its author:

• reptyr: Attach a running process to a new terminal
• reptyr: Changing a process’s controlling terminal

To steal a process from one tty to your current tty, you may want to try this hack:

http://www.ucc.asn.au/~dagobah/things/grab.c

It needs some reformatting in order to compile to current Linux/glibc versions, but still works.

When a process starts, STDIN, STDOUT and STDERR are connected to something. Generally you can't change that once the command is started. In the case you're describing, that's probably a tty associated with the ssh session. nohup pretty much just does ...

command < /dev/null > nohup.out 2>&1

That is, sets STDIN to /dev/null, STDOUT to a file and STDERR to STDOUT. Screen does much more sophisticated things involving setting up ttys that direct to itself.

I don't know of any way to retroactively nohup or screenize a running process. If you cd to /proc/$pid/fd and see what 0, 1 and 2 point to.

You might have some luck with disown, but not if the process tries to do anything with STDIN, STDOUT or STDERR.

I can only give you a simple "No" without the why for the screen part, I'd be interested in the reason myself thou.

However have you tried disown (a bash builtin)

~ $ echo $SHELL
/bin/bash
~ $ type disown
disown is a shell builtin
~ $ 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.

Cryopid is a further development from the author of grab.c that freezes a process to a file, which you then run (inside screen) to resume the process.

nohup on Solaris/OpenSolaris has a -p flag to nohup a running process - for instance, see the Solaris 10 nohup man page.

I recently saw a link to neercs, which is a screen-like utility built using libcaca, a colour ascii-art library. Amongst other features, it boasts the ability to grab an existing process and re-parent it inside your neercs (screen) session.

I've not used it however, so I cannot comment on whether it works or not.

I'm probably under-thinking this so feel free to correct me (I already learned about disown!)... Wouldn't a ctrl-Z and "bg" work to at least get the process running in the background? Or is the key issue that you'd still want to see STDOUT while it runs?

If you can live with not being able to interact with the process and you don't object to loading random kernel modules, you could do worse than to look at Snoop. Alternatively, there are a couple of other projects. Here is one call injcode, which can mostly do what you want to do.