Possible Duplicate:
How can I disown a running process and associate it to a new screen shell?

It is a good practice to run long processes in screen session, to protect them from session hangups. But what should I do if I already have a process that is running and I just forgot to run screen? Is it possible to 'capture' current session somehow and protect it with screen?

marked as duplicate by jasonwryan, Renan, Gilles, manatwork, Mat Nov 22 '12 at 7:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


You want to have a look at the retty program. It's homepage is http://pasky.or.cz//dev/retty/

The idea is to redirect your stdin/stderr/stdout, which you can do with gdb, but this tiny program makes it much easier to do so. It is not perfect, but should do the job.

  • 1
    Note that it's only for Linux and only some architectures (no amd64 for instance) and have more limitations than reptyr brought up by @angus. – Stéphane Chazelas Nov 21 '12 at 16:17

Apart from the already mentioned retty and reptyr, neercs and injcode offer the functionality as well.


Not really.

The closest you could get is:

Start a new screen window, run:

trap '' INT HUP
exec sleep 99999999

in it. Record the tty for that window ($tty).

Use lsof to figure out what fds of what processes in the session are open to the current tty.

With gdb, attach to every process in the session, do some call signal(1,1) to ignore the SIGHUPs. For the session leader, you'll probably need to do a call dup2(0,1023) (assuming 0 is opened on the tty) to keep a fd open on the old terminal. Then for each process, do

set variable $fd = open("the-screen-window-tty",2)

Then for each fd that was open on the old terminal, do:

call dup2($fd, that-fd)

And then:

call close($fd)

The session attached to the new terminal would be the one with that "sleep" process as the leader (and only process) though, things like window resizing, CTRL-C, CTRL-Z, job control, /dev/tty won't work and probably a few more nasty side effects I don't think of.

If on Linux, reptyr, brought up by @angus in a comment to your question, automates that process and addresses the shortcomings above by creating a new pty and make that controlled by the process you want to migrate. However, it only supports migrating one process AFAICT.

Not the answer you're looking for? Browse other questions tagged or ask your own question.