Bash/ZSH: Undoing 'disown'

Question

Is there a way to 'reattach' a process to the shells job table after it it has been 'disowned'?

Edit: $SEARCHENGINE totally fails me. Doesn't look too good.

Solution 1

Considering how linux jobs and process ownership works, I'm afraid it's not really possible to re-own a process, without help from the adopting process.

A parent may 'disown' a child, which is then 'adopted' by the process named 'init'. System security prevents someone from grabbing someone else's processes. When you disown it, a process becomes someone else's (init's) to control. You as the 'user' could still kill the process, but you can't get it back. Attempting to coerce init to return your process is unlikely to work, as init doesn't even read mail.

As mean as it sounds, it really boils down to the answer of "Don't do that!".

Solution 2

While I assume this doesn't help anyone in the unfortunate situation of having disowned the wrong process, if you were to banish disown from your workflow and replace it with:

https://github.com/nelhage/reptyr

You would be able to reparent any process (i.e. move it inside screen).

Solution 3

All you need is reptyr. It lives on GitHub and has been packaged for Debian since Wheezy, and probably for other GNU/Linux distros, too. It will foreground your disowned process in the current terminal if you invoke it with its process ID (PID). So for example:

pgrep -f DISOWNED_PROCESS  # to find out the PID of the disowned process
reptyr PID                 # insert this PID here

Solution 4

Sorry, no. In principle, it would be possible, since disowning merely changes some shell internal state — it basically removes the process ID from a list, and it could be put back without too much hassle (you'd have to be a little careful in testing that the reattached pid is in the right session, but that's not insurmountable). But none of the usual shells (bash, ksh, tcsh, zsh) seem to have a way to re-add . (Though with zsh you can write to the jobstates, jobdirs and jobtext associative arrays; I don't know how much you can achieve that way.)

If you want the shell to send signals to the disowned process as it does for its owned subprocesses, you can write a stub job that waits until it receives a signal and sends the same signal to the disowned process. You can send SIGSTOP and SIGCONT to the disowned process to simulate Ctrl+Z and bg. None of this will be quite as convenient as re-owning.

View more solutions

Comments

[nisc]

The circumstances are: You disown the wrong process and want to get it back.

[Scott]

Ah. Harder. Screen needs to be foreplanned.

[Gilles 'SO- stop being evil']

This can't be right: the parent process can't cause the child to be adopted except by exiting. The behavior you describe has to be triggered from the child process (or by the kernel, which does some of this automatically if the parent dies). A process can't adopt a child voluntarily but it can't give one up either.

[alpha]

My apologies. My Fault. Oversimplified too much. Ran through the bash source again, bash still retains ownership, but inhibits sighup being passed down to the child process. So it MIGHT be possible to get it back, but it's not built into bash (yet). For some reason I got stuck on init's reaping of orphans and zombies.

[hlovdal]

Well, I got back my disowned vim process with reptyr, so it worked just like the un-disown utility I was looking for.

[Anand Bhararia]

@lomix yeah, but when you quit the shell you disowned it from, then it does get a ppid of 1. so your reasoning is valid. who disowns unless they about to exit anyway :p

[Christian Pietsch]

You are right, @hlovdal: This answer is half-wrong. reptyr is the solution, but there is no need to stop using disown. For clarity, I have written a new answer.

[Christian Pietsch]

Sorry, but this answer is wrong. Just use reptyr (see my answer for a usage example).

[FizxMike]

(sudo apt-get install reptyr) Then got this on first attempt: "The kernel denied permission while attaching. If your uid matches the target's, check the value of /proc/sys/kernel/yama/ptrace_scope. For more information, see /etc/sysctl.d/10-ptrace.conf" I changed the value in both locations from 1 to 0 and it worked. I tested a disown and reptyr of a process as the same user (ipython notebook on ubuntu 14.04 LTS). Perhaps this is okay for development in an isolated environment... not sure the ultimate security ramifications of the change however. Maybe someone with expertise can chime in.