New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

This comment has been minimized.

bjovanovic commented Apr 11, 2014

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

This comment has been minimized.

piotrkochan commented May 9, 2014

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

@nelhage

This comment has been minimized.

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

This comment has been minimized.

droidzone commented May 17, 2014

Would have been a pretty useful feature to have

@stuartpb

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

drocsid commented Nov 25, 2014

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

@cuteboi

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

melikyuksel commented Apr 2, 2016

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

@nelhage

This comment has been minimized.

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

This comment has been minimized.

mystica555 commented Apr 11, 2016

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

This comment has been minimized.

infinity0 commented Dec 13, 2016

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.

@akashagarwal7

This comment has been minimized.

akashagarwal7 commented Jan 8, 2017

@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

This comment has been minimized.

infinity0 commented Jan 8, 2017

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

@JeromeJ

This comment has been minimized.

JeromeJ commented May 18, 2017

Completely ignore the -T argument for me, it isn't even listed in --help. I got version 0.5, when has this been implemented? I've got the latest version offered by my source depot on Debian 8.

@Sandoras

This comment has been minimized.

Sandoras commented May 21, 2017

@JeromeJ I have the exact same problem. I found out I have the 0.5 version also, which is about 4 years old now. Since I am new to Linux all in all, I need to figure out how i can upgrade something that is already in the source depot.. Oh well, at least I'm having fun.

@Smattr

This comment has been minimized.

Smattr commented May 22, 2017

@Sandoras you're new to Linux but you're running reptyr... You really have chosen to dive in at the deep end :)

Some minimal steps to get a runnable version of the github tip if you don't care about Bash completion and do not have root/sudo:

$ git clone https://github.com/nelhage/reptyr
$ cd reptyr
$ mkdir -p /path/where/reptyr/will/live
$ make PREFIX=/path/where/reptyr/will/live BASHCOMPDIR=$(mktemp -d) install
$ /path/where/reptyr/will/live/bin/reptyr --help

HTH

@Sandoras

This comment has been minimized.

Sandoras commented May 22, 2017

@Smattr Thank you! I already installed the 5.0 version of reptyr via apt-get. This will still work? And what directory do you suppose I can put it in?

@Smattr

This comment has been minimized.

Smattr commented May 23, 2017

Did you mean version 0.5? It doesn't look to me like it's reached 5.0.

As far as I'm aware, the two versions should happily co-exist if that's what you're asking. You might want to uninstall the apt-get-provided version to avoid confusion though.

With regards to what directory to put it in, Linux isn't particularly picky about where you put things. For example, you could install it to ~/reptyr and then run it as ~/reptyr/bin/reptyr. If you want to be able to run it by just typing reptyr you'll want to look into modifying your PATH variable and your ~/.bashrc or equivalent. Some searching online should turn up plenty of advice for doing this.

@BarbzYHOOL

This comment has been minimized.

BarbzYHOOL commented Aug 18, 2018

I get this when trying the -T Child is not connected to a pseudo-TTY. Unable to steal TTY

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