Similar to many previous questions, I found myself running a job that I wish I had run in screen. I was forced to disown the process because I needed to disconnect. Now that I have reconnected, I see that the process is still running. How can I "reclaim" the process, so that I can see its output and give it input?

This question is distinct from just moving a running process to screen, in that it involves reopening lost stdin/out/err handles.


This is a duplicate question — see Moving an already-running process to Screen , which points to retty, which is a self-described horrible hack implementing what I'd always guessed might be possible but never really tried: it finds fd 0, 1, and 2 (standard in, out, and error, respectively) for the process and attaches to them, like a horrible aberrant parasite which should not be.

  • I didn't know about this program--although truth be told, its not good practice to use it! Good answer, regardless.
    – Andrew M.
    Nov 24 '10 at 4:18
  • What's the problem with it? Isn't this exacty how you reown a process after disowning it?
    – Paul
    Jun 10 '20 at 14:50

By disowning the process, you are effectively saying that you want it to ignore SIGHUPs issued by the terminal. Once you close your session (say, bash), this process will then become owned by init. So when you say you want to re-own a process after you've given up ownership, you're saying you want to take ownership away from another process--which isn't implemented, and for good reason. This just isn't possible to do gracefully in Linux.

  • 1
    Processes don't own other processes quite like that. A disowned process is still running as you.
    – mattdm
    Nov 24 '10 at 4:05
  • They do once the parent session has been closed--as indicated by his question. I updated my answer to reflect this.
    – Andrew M.
    Nov 24 '10 at 4:13
  • The parent process changes to init, but that's different from ownership. The EUID and UID of the process remain that of the original user. Otherwise, this could be potentially exploitable, because every user would suddenly have a way of running code as another user, and a system user no less.
    – mattdm
    Nov 24 '10 at 4:32
  • 1
    EUID/UID != PPID. I'm talking about process ownership, not permissions.
    – Andrew M.
    Nov 24 '10 at 4:39
  • 1
    Clearly, this is a failure in my terminology. To clarify, I'm using ownership to mean which parent process is responsible for the child process. That is, in my explanation, "a is the parent process of b" means "a owns b", where a and b are processes, not users.
    – Andrew M.
    Nov 24 '10 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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