20

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.

Sparr
  • 770
  • 1
  • 5
  • 14
  • 2
    Possible duplicate of [Moving an already-running process to Screen](http://serverfault.com/questions/55880/moving-an-already-running-process-to-screen) – mattdm Jan 29 '16 at 12:37

2 Answers2

8

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.

Community
  • 1
mattdm
  • 6,550
  • 1
  • 25
  • 48
  • 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 04:18
  • 1
    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
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.

Andrew M.
  • 10,982
  • 2
  • 34
  • 29
  • 1
    Processes don't own other processes quite like that. A disowned process is still running as you. – mattdm Nov 24 '10 at 04: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 04: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 04:32
  • 1
    EUID/UID != PPID. I'm talking about process ownership, not permissions. – Andrew M. Nov 24 '10 at 04:39
  • Yes, I think we agree about everything except for the meaning of the term "process ownership". This refers to the user id with which the process is associated, not its parent process. Maybe the confusion is due to the `disown` bash-specific command, which, despite the name, actually has nothing to do with changing process ownership. – mattdm Nov 24 '10 at 14:50
  • 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