30
12
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.
30
12
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.
16
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!".
18
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).
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 – 2015-06-10T12:26:47.720
2Well, I got back my disowned vim process with reptyr, so it worked just like the un-disown utility I was looking for. – hlovdal – 2013-02-20T13:33:33.067
11
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
2(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. – FizxMike – 2015-11-04T20:58:23.120
1
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.
0
What are the circumstances? If you just want to get your terminal back for a while, you could use GNU Screen instead. It doesn't quite detach the process from a terminal - Screen emulates one for the process's benefit - but you can attach and detach it from the real terminal that you're using. You can even detach a screen, log out, then log back in and re-attach to the same screen.
6The circumstances are: You disown the wrong process and want to get it back. – nisc – 2010-09-02T22:59:44.187
1Ah. Harder. Screen needs to be foreplanned. – Scott – 2010-09-03T06:27:46.753
1Sorry, but this answer is wrong. Just use
reptyr
(see my answer for a usage example). – Christian Pietsch – 2015-06-10T12:29:06.6471This 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. – Gilles 'SO- stop being evil' – 2010-10-29T17:41:42.210
1My 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. – lornix – 2010-10-29T18:28:23.643
@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 – Orwellophile – 2013-12-15T02:46:31.517