Doesn't work for processes which have spawned subprocesses #24

Closed
prologic opened this Issue May 3, 2013 · 17 comments

Projects

None yet
@prologic
prologic commented May 3, 2013

See:

# 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
@bjovanovic

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)...

@piotrkochan

It'll be really good to develop this feature. therealprologic commented a year ago...

@nelhage
Owner
nelhage commented May 9, 2014

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.

@droidzone

Would have been a pretty useful feature to have

@stuartpb
stuartpb commented Aug 3, 2014

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.)

@nelhage
Owner
nelhage commented Aug 15, 2014

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.

@drocsid
drocsid commented Nov 25, 2014

I'm running as root using sudo -i, but get unable to attach to pid 3822: Permission denied

@cuteboi
cuteboi commented Dec 1, 2014

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

@Smattr
Smattr commented Dec 3, 2014

This is really cool. Impressive lateral thinking, Nelson.

A couple of initial surprises that I'm not sure I'd consider bugs:

  1. You can't seem to re-parent a session twice. E.g. if I use reptyr -T 3822 to grab a target session everything works as expected and subprocesses seem to have the same PIDs. However, if I open a new terminal and run reptyr -T 3822 again it can't seem to find the (still existing) session. I get [-] Unable to find the fd for the pty!.
  2. Exiting a backgrounded process of the original terminal leaves it suspended. I.e. If you open a process "blah", background it, then reptyr another session, then exit "blah", it remains suspended. After exiting the reptyred (is that an acceptable verb now?) session "blah" is still suspended and you need to foreground it to have it terminate.
@nelhage
Owner
nelhage commented Dec 3, 2014
  1. is expected, because of the heuristic reptyr uses to find the terminal emulator (after attach, the reptyr becomes the new terminal emulator). It would be possible to fix this with a little creative work.
  2. I'm not quite sure what situation you're describing here. Can you be more specific about specifically which processes are doing what?
@Smattr
Smattr commented Dec 4, 2014

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.

@nelhage nelhage closed this Jan 4, 2015
@melikyuksel

Why was this closed even though it still doesn't work?

@nelhage
Owner
nelhage commented Apr 2, 2016

@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.

@mystica555

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!

@infinity0

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.

@akashaggarwal7

@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?

@infinity0

@akashaggarwal7 not sure, but you can run pstree -alpu to see which processes still exist and how they're all related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment