Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
    
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

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.

share|improve this answer
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
    
EUID/UID != PPID. I'm talking about process ownership, not permissions. –  Andrew M. Nov 24 '10 at 4: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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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