Can one access an open terminal on the computer via SSH?

Question

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?)

Solution 1

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.

Solution 2

Since you have tagged this gnome-terminal, 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.

Comments

[Panther]

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.

[ck4e]

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?

[Panther]

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 - xpra.org but again it has to be running BEFORE you start your terminal.

[ck4e]

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.

[Panther]

Possible - muru posted a suggestion, but the data is likely encrypted. "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 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.

[ck4e]

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.

[fkraiem]

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

[ck4e]

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]

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]

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.

[Jo-Erlend Schinstad]

I think I'd rather recommend X2go than FreeNX.