23

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.

1

3 Answers 3

10

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.

2
  • 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, 2010 at 4:18
  • 2
    What's the problem with it? Isn't this exacty how you reown a process after disowning it?
    – Paul
    Jun 10, 2020 at 14:50
7

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.

6
  • 1
    Processes don't own other processes quite like that. A disowned process is still running as you.
    – mattdm
    Nov 24, 2010 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, 2010 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, 2010 at 4:32
  • 1
    EUID/UID != PPID. I'm talking about process ownership, not permissions.
    – Andrew M.
    Nov 24, 2010 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, 2010 at 15:42
1

You can use reptyr for this:

./long-running-process &    # notice the PID
disown

reptyr pid-of-process

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .