[Gllug] Re-access broken remote connection to process?
nix at esperi.org.uk
Mon Jun 21 19:45:41 UTC 2010
On 21 Jun 2010, Robert McKay outgrape:
> On Tue, Jun 15, 2010 at 8:08 PM, gvim <gvimrc at gmail.com> wrote:
>> Supposing I'm connected remotely to a server process via SSH and I lose
>> that connection. The process is still running and it's ID is available via
>> top or ps but can I get its output back into a tty? If so, how?
> You can attach to the process with a debugger, open a new tty and then dup
> stdin/stdout/stderr to the new tty. I once wrote a shell script to automate
> this process. It does work - however not always for various reasons.
Congratulations for the most evil hack I've seen all year. You deserve
some kind of award, or possibly a long period in a prison hospital ;P
This will probably work *if* the process isn't doing elaborate things
with terminal settings. It's likely to go horribly wrong if the program
is using something like curses, just as it would if you hit your
terminal's reset option while running such a program.
> note: it needs /dev/ttypX /dev/ptypX devices so if you don't have those
> (modern linux distributions tend to only come with /dev/pmtx) you'll need to
> create one first using:
Many modern Linux systems have support for these compiled entirely out of
the kernel. Why can't you just open /dev/ptmx instead?
> echo 'call setsid()'
> echo 'call close(0)'
> echo 'call open("/dev/ttyp1", 66, 0666)'
> echo 'call dup2(0, 1)'
> echo 'call dup2(0, 2)'
> echo 'call dup2(0, 4)'
> echo 'call dup2(0, 5)'
> echo 'call dup2(0, 6)'
4, 5, and 6, what on earth? Why blow away three random files the process is
(possibly) holding open and replace them with your TTY?
> echo 'call ioctl(0, 21518, 0)' # set new controlling terminal
> echo 'call signal(1, $1)' # replace signal handler
GAH ugh my head just exploded, there must be a better way.
Gllug mailing list - Gllug at gllug.org.uk
More information about the GLLUG