Doesn't work for processes which have spawned subprocesses

[prologic]

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]

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]

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]

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.

[apple-corps]

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

[cuteboi]

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 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]

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]

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.

[melyux]

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

[nelhage]

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

[akashagarwal7]

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

[JeromeJ]

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]

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

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

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

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]

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

[RSully]

@BarbzYHOOL did you ever find a solution to this? I have a process that I failed to capture and is now a child of systemd that gives that error

[Smattr]

I don't know how far into debugging this you are but if it helps, the symptoms indicate your process is not connected to a Unix 98 PTY.

[Aside @nelhage, is it deliberate that parse_proc_state uses %u for the device number while the manpage documents it as %d? I can't see how this would make a difference to the case mentioned above but it seemed surprising.]

[nelhage]

@Smattr I don't think there was any reason for that, but I also agree I can't imagine it causing problems in practice.

[nelhage]

(I'd happily take a PR to fix if you're feeling motivated)

To the original question, -T can't really work, at least I'm not quite sure what it would mean for it to work, if the process isn't attached to a TTY.

[RSully]

Yeah I understand -T would be undefined in this state, I suppose the question is there anything reptyr can do when a process is in this state, thinking outside the box perhaps?

[cormacncheese]

Still getting the following error when using -T

Child is not connected to a pseudo-TTY. Unable to steal TTY.
Unable to attach to pid <PID>: Invalid argument

Any workaround for this? I'm logged in as root

[KaKi87]

it won't normally work on sessions that are spawned out of an ssh session unless the attaching reptyr is run as root

What if the initial command was run as another user than root ?

I'm currently in that case, and running reptyr -T <pid> as root throws permission denied, which I suppose is because of that.

Thanks

EDIT: sorry for the duplicate comment, I first got an error saying that submitting failed, while it actually didn't.