6

I'm looking to access an open terminal, that is, opened locally on my machine, from a remote computer without using tmux or screen. There's a few reasons for this, the simplest of which is that I keep landing up with a situation where I didn't plan ahead, run something big on my pc at work, go home and then want to check on it via ssh.

In essence I'm looking for a way to attach to the terminal already running on a computer and view its output.

Now, I know that there are a few threads out there that say you can't do this (such as this one ), and others that simply recommend screen and tmux (like this one, this one or this one). What I'm looking for is a way to directly access a running terminal process, or at the very least see the cached output of that terminal. I don't necessarily need to be able to enter commands in that terminal.

Is there a way to do this? Otherwise, any ideas on a hack that could work? I was thinking I could probably find a way to automatically log stdout, stderr and the commands to a file (perhaps a clever tweak on bash history that logs everything?)

ck4e
  • 91
  • 1
  • 4
  • 6
    Well, this is exactly what screen and tmux are designed to do so use one of those two options. Your only other option would be to use Freenx or other VNC server over ssh that would be the entire desktop but honestly your problem is your refusal to use screen and the solution is simple, use screen. – Panther Jul 27 '17 at 22:14
  • Yeah, that's a fair point, and thanks for the advice. I still believe that a viable solution should be possible, and I was interested to know what options were available - not only because this happens to me occasionally, but it happens to folks that I work with. So in a given situation, where it is too late for a clever solution involving screen or tmux, what can we do to get the output of a terminal back? Can one access that terminal again? – ck4e Jul 28 '17 at 19:07
  • Well, the problem is that you are not running screen, if you were you would not have this problem in the first place. so your reasoning is circular. Because I refuse to use screen I have a problem that screen was designed to solve. There is no way to do this after the fact. Before you run the command in the terminal, start a VNC server such a FreeNX or before you run the command start screen or tmux. You can try Xpra - http://xpra.org/ but again it has to be running BEFORE you start your terminal. – Panther Jul 28 '17 at 19:26
  • If its not possible, its not possible. I'm not really sure how to make this more clear - its not that I'm avoiding screen or tmux or any of the other solutions out there. I'm quite happy to use them, and will likely set things up later to ensure that I don't run into problems like this again.

    But the academic question remains - is there a way to access the content of a terminal if one has not run screen or tmux. I do not know if there is, but it seems plausible that there could be. Hence the question.

     – ck4e Jul 28 '17 at 19:34
  • Possible - muru posted a suggestion, but the data is likely encrypted. "ls -l /proc//fd to see what they point to. Then you can cat these to make a new file. These are just a verbatim copy of the terminal output. No compression. No nothing." but then "vte-0.40 (which will most likely appear in Ubuntu 15.10 W.W.) will compress and encrypt these files." . Did you try this ? I suppose it is possible for you to break the encryption. Is it feasible is a better question. – Panther Jul 28 '17 at 19:40
  • It is an interesting idea. I haven't had much luck yet with this but I'm digging into it a bit. Most of the file descriptors for my gnome-terminal process point to /dev/ptmx, /dev/null, or are associated with deleted tmp files (eg. /tmp/#6422705 (deleted)). I'm going to poke around with this a bit and see what comes of it. – ck4e Jul 28 '17 at 19:50
  • "I was thinking I could probably find a way to automatically log stdout, stderr and the commands to a file" script does that, but then again if you can remember to run your commands in script, you can also remember to run them in tmux... – fkraiem Oct 26 '17 at 10:41

4 Answers4

5

Simply due to how terminals are built, it is not possible to access everything, i.e. you cannot view a running terminal and interact with it if you don't have a detachable session running within the said terminal, such as screen or tmux session, or if you haven't started that command with logging via script command.

What can be done is partially view TTY via sudo cat /dev/vcs1 command. /dev/vcs[1-6] correspond to their respective TTY consoles. This is limited by the scrollback buffer size of the respective TTY, which means you can only see whatever is held in memory up to certain number of lines. This of course can be tuned to increase the number of lines as shown in muru's answer here. Alternatively, you probably should try 

setterm -file log.txt -dump [ttynumbers]

which was mentioned in this ssh question.

At the end of the day, bodhi.zazen properly noted in their comment, that your refusal to use screen or tmux is the biggest problem. I totally understand, I often forget to track long-running programs myself, but with some commands you should start thinking ahead.

Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • Thank you so much for your answer. I've tried both cat /dev/vcs1 and setterm with limited results, but certainly better than what I had before.

    Again, I would caution against calling it a refusal - I recognize that I can use it, and occasionally do. My question was more what options are available to me, if I hadn't initiated screen or tmux.

    I've taken a look at script and one of my options at the moment is to add a simple function to my .bashrc to initiate logging of general terminal output to some log file somewhere. A general solution remains of interest however.

     – ck4e Jul 28 '17 at 19:21
  • I could, of course, add a screen command to my .bashrc - perhaps something along these lines. I gather that such a solution isn't ideal though, and I'd be interested in other options. It is of course, not general, and would not resolve the general problem if one hasn't started screen or tmux – ck4e Jul 28 '17 at 19:24
2

Since you have tagged this , depending on the version, it might be possible to view part of the output. From this blog post, where the author wanted to see what GNOME Terminal does for "unlimited" scrollback:

I could just look at what files gnome-terminal had open, so lsof to the rescue. Then I found it was being sneaky, it had a number of files called /tmp/vteXYZ1tv open, but it had already deleted them. Thus you can't see them when browsing, and they will be removed when the program closes. [...] They can be restored though, my way (there are probably others), was to do a ls -l /proc/<gnome-terminal pid>/fd to see what they point to. Then you can cat these to make a new file. These are just a verbatim copy of the terminal output. No compression. No nothing.

But in newer versions, the files are supposed to be encrypted. From this answer:

vte-0.40 (which will most likely appear in Ubuntu 15.10 W.W.) will compress and encrypt these files. This will shrink the required storage to approx third–fourth of its size (if your app produces X amount of data as plain text, somewhere between X/4 .. X/3 is a reasonable estimate for the storage that'll be required), and also gets rid of the privacy/security issue in case someone gets raw access to the hard drive.

If you only want future output, you could try dragging the process to a new TTY using reptyr.

muru
  • 197,895
  • 55
  • 485
  • 740
1

Depending on the process running inside the terminal, you might have success by peeking into the state and the actions made by that process rather than what it has displayed in the terminal.

A few examples, assuming you've somehow figured out the PID (process ID) of the given process (e.g. using pidof or ps):

  • If the given tool launches subcommands one by one, check which one is running using ps.

  • If the given tool sometimes changes its working directory, check that at /proc/<PID>/cwd.

  • If the given tool operates on many files in a row, check which one's open under /proc/<PID>/fd. If you can't see any at the moment, it might be that your process has just closed one and is about to open the next; check again a few times for the contents of that directory.

  • If the command operates on a single huge file using the standard read/write syscalls, you can find the file descriptor number under /proc/<PID>/fd and check for the current offset in the corresponding file under /proc/<PID>/fdinfo. If the command uses pread/pwrite instead then see the next bullet point.

  • You can connect to the process using strace to see what it's doing: strace -p <PID>. Quit shortly afterwards using Ctrl+C (it terminates strace only, not the application you're tracing). Examine the output and look for relevant stuff that might give you an idea. Use for example the -e trace option to restrict this output to file operations only. You'll see e.g. the filenames that are being opened by your applications, as well as the offsets where pread/pwrite operations happen.

egmont
  • 8,225
0

From the comments, there are several potential solutions, but they all have to be implemented BEFORE you run the command in the graphical terminal.

For example, see https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1356433

So users within the same X session can not reconnect to closed tabs.

You can try reptyr as suggested by muru, and this is a cool solution, but better to plan your ssh sessions better from the start.

You need to develop a better working strategy.

  1. Use screen or tmux or similar. These tools were designed for exactly this scenario.

Personally I use screen as I am familiar with it and for the reasons you state I always use a screen session over ssh, ie I start screen and verver really exit the screen session. Often I have more then one screen session, one for each VM on a host for example.

  1. Use a VNC server. You can run the session over ssh (VNC-over-SSH) or use FreeNX which is faster and more secure. DO NOT RUN A VNC SERVER OVER "THE INTERNET" WITHOUT SSH OR FREENX

VNC over ssh - https://www.cyberciti.biz/tips/tunneling-vnc-connections-over-ssh-howto.html

FreeNX - https://www.howtoforge.com/tutorial/freenx-ubuntu-14-04-trusty-tahr/

  1. You can use Xpra

https://help.ubuntu.com/community/Xpra

http://xpra.org/

With xpra you can start and then reattach the graphical terminal, but again you have to be running xpra before you start the terminal.

Panther
  • 102,067
  • Yes, VNC, screen, tmux, are all good solutions with a little forethought. That bug however does not imply that the content of a terminal cannot be accessed - it just implies that tab control in gnome-terminal is perhaps a little buggy.

    Regardless, I really agree with your point about a better working strategy and I've been investigating different options for that. I'm not sure which way to go but I'm leaning towards starting a screen session on startup and using a .bashrc command to attach to attach a session with every new terminal.

     – ck4e Jul 28 '17 at 20:08
  • I think I'd rather recommend X2go than FreeNX. – Jo-Erlend Schinstad Jul 28 '17 at 20:46