# reptyr $(pgrep pkgmk)
[-] Process 4646 (pkgmk) shares 4604's process group. Unable to attach.
(This most commonly means that 4604 has a suprocesses).
Unable to attach to pid 4604: Invalid argument
No updates? This is showstopper for pretty much any shell process that does something.. Being able to use reptyr would be great to be able to reattach to long running shell scripts remotely/safely... (once you figure out they are taking too long)...
It'll be really good to develop this feature. therealprologic commented a year ago...
Yeah, I'd really love to have this feature, but I've given it a bunch of thought and experimentation, and don't know of a robust way to do it with the operations Linux gives you. I came up with a completely different approach involving stealing the pty, but unfortunately it won't work for things started directly from an ssh session, which is much of the utility of reptyr :/
If that'd be useful, I'd consider doing a prototype, but I just don't know how to do this in general.
Would have been a pretty useful feature to have
If the kernel features currently available aren't sufficient, perhaps this calls for some new kernel features? (Hell, that's what Google did with cgroups, and had they not we wouldn't have systemd or Docker.)
reptyr master now includes a -T option, which uses an entirely different attachment strategy that, among other advantages, will attach the entire target terminal, including all processes. I still consider it experimental, but I'd appreciate testing and bug reports.
One known limitation, unfortunately, because of how it works and an interaction with how setuid works on Linux, is that it won't normally work on sessions that are spawned out of an ssh session unless the attaching reptyr is run as root.
I'm running as root using sudo -i, but get unable to attach to pid 3822: Permission denied
if you're using Ubuntu, there are rules in place to prevent you from doing that. http://www.bay12forums.com/smf/index.php?topic=65326.0
This is really cool. Impressive lateral thinking, Nelson.
A couple of initial surprises that I'm not sure I'd consider bugs:
reptyr -T 3822
[-] Unable to find the fd for the pty!
Sorry, disregard the second point. I was experimenting using mplayer and it turns out this is normal behaviour outside the context of reptyr. E.g. Start mplayer, Ctrl+Z, bg, quit mplayer. Mplayer remains suspended in the background until you fg it and it terminates.
Why was this closed even though it still doesn't work?
@melikyuksel It should work with -T in most cases, and I don't know of a way to make it work in reptyr's default mode, due to fundamental limitations of the terminal APIs exposed by the kernel. If you have specific issues with -T, feel free to open a new issue.
reptyr -T worked fine for me with a stuck old dpkg process that spawned a whiptail subshell for configuration options from another ssh session.
Great work and Thanks!
You can reptyr -T the same process twice, the second time you just have to give the PID of the reptyr process that you used the first time.
Your terminal ends up in a weird state where you can type in commands but the process is running "at the same time" in the background, but since it is not a direct child of the shell, you can't do fg or bg to get it back under your control.
Still, it's useful if you need to move a long-running build process around into a different terminal just to keep it alive, for whatever reason.
@infinity0 Thanks! That worked wonders. Quick question, if I have to do it for the third time, I'd still be using the PID of first reptyr right?
@akashaggarwal7 not sure, but you can run pstree -alpu to see which processes still exist and how they're all related.