Doesn't it work if the parent has child processes?

[manjusm]

~/reptyr-master$ ./reptyr 946227
[-] Process 946489 (gmake) shares 946227's process group. Unable to attach.
(This most commonly means that 946227 has sub-processes).
Unable to attach to pid 946227: Invalid argument

Regards,
Manju

[nelhage]

It may work better with `-T`, which uses a different strategy to attach. But the default mode of operation cannot attach processes with children.

…

On Tue, Jun 20, 2017, 08:41 Manjunatha S M ***@***.***> wrote: ~/reptyr-master$ ./reptyr 946227 [-] Process 946489 (gmake) shares 946227's process group. Unable to attach. (This most commonly means that 946227 has sub-processes). Unable to attach to pid 946227: Invalid argument Regards, Manju — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#84>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABBVZhYASfxqkfJVpkCz9c5yirZknk9ks5sF-gogaJpZM4N_xxT> .

[SRGOM]

For me, scala programs run using sbt fail to re-attach despite trying -T on parent sbt process.

[wsdjeg]

now neovim and vim8 support job, so they have suprocesses.
when I use this tools I get:

[-] Process 8411 (python2) shares 8407's process group. Unable to attach.
(This most commonly means that 8407 has suprocesses).
Unable to attach to pid 8407: Invalid argument

[olaulau]

same with rsync :-(

[BarbzYHOOL]

I get this when trying the -T Child is not connected to a pseudo-TTY. Unable to steal TTY the process was started with the "at" command though :D

[jglapa]

I have the same problem when I start a command with sudo that spans a new subprocess with the actual command

[michaelpalumbo]

did you try the -T command? see #24

it worked for me on raspbian lite where I had started a process over ssh and then ran

sudo reptyr PID -T

note that there seemed to be no response in the terminal on the target machine for a few minutes, until it finally began printing the stdout. just writing this to encourage patience :)

Many thanks @nelhage for reptyr and providing the -T -- now I can leave for and not worry about restarting an already 10-hour make process on an rpi zero...

[SR-G]

I'm trying to recover a process still running in a docker container and started through "docker exec" (the global window has been lost, but the execution is still running in the background, and i would have been willing to recover the output as it's a very long processing).

By default (without any paramters), reptyr fives the same error messages about child processes, but when using the -T feature, i get something else, does anyone have an idea about it ? (of course i'm still logged inside the container as the same user, which in my case - this is a test container - is the root account (UID=GID=0)

root@7de93b6ab1af:~# reptyr 4863 -T
Unable to attach to pid 4863: Operation not permitted
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 have the value 1 in the referenced file, but i'm not sure what it may mean)

Maybe it's just related to how docker works ? (that is, reptyr inside the container is trying to access some processes informations only owned by the underlying kernel ? (hence the errors)

[mihaitodor]

@SR-G It might be due to not starting the container with --privileged (or maybe --cap-add=SYS_PTRACE is sufficient), since reptyr seems to depend on ptrace. I wonder if it might be possible to call reptyr from the host directly, but I wasn't successful when trying in a DinD container... Would be cool to have support for this, though :)

[darioackermann]

@SR-G Not sure if this still is a topic for you, probably not, but the value in the referenced file (ptrace_scope) should be 0 AFAIK.

[cormacncheese]

Any update on this error?

Child is not connected to a pseudo-TTY. Unable to steal TTY.

[HenkPoley]

Maybe add a hint that -T might work to the "This most commonly means that" message ?

You might want to suggest to use pstree --show-pids to trace to the highest shell process to 'steal TTY' from.

[wuzirui]

did you try the -T command? see #24

it worked for me on raspbian lite where I had started a process over ssh and then ran

sudo reptyr PID -T

note that there seemed to be no response in the terminal on the target machine for a few minutes, until it finally began printing the stdout. just writing this to encourage patience :)

Many thanks @nelhage for reptyr and providing the -T -- now I can leave for and not worry about restarting an already 10-hour make process on an rpi zero...

Hi @michaelpalumbo! I've tried the command and it does not work, do you have any idea? Thanks!

> sudo reptyr 1290042 -T
Unable to attach to pid 1290042: Permission denied

the process (1290042) is created by:

sudo cp /deva /devb

[cooljeanius]

I think this issue is the one currently preventing me from using this with the GCC testsuite on the GCC compile farm; the -T option doesn't help...