I am filing this under “I am doing Linux wrong, but I don’t know where.”
I am connecting to Linux boxen via Windows.
Rather than running an X environment, I am using ssh
to get a command line. I am using PuTTY on Windows.
Originally, I was getting disconnected by one of the Linux machines if I walked away for an hour. Eventually, I taught PuTTY to send keepalive messages, and that problem stopped.
All was good for a while. Then I finished running batch processing jobs all night on the Windows box, and the Windows automatic hibernation started cutting in, to save power.
Now, when the Windows machine woke up, the PuTTY application was still running, but the TCP session had expired. PuTTY tries to be helpful about continuing to show the session information, but it is still confusing to have these old windows open that look ready to take input, but beep when you type.
I was living with this need to reconnect each day, for a long time. Then I started using virtualenv
, to allow me to separate the Python environments that I used for development, for the production system and for applications directly using the OS.
Now, I had a command I had to run each time I connected. If I didn’t run it, I would get random errors as slight differences in Python versions and available libraries caused problems.
I added some version checking in some of my key long-running programs, so they die immediately and loudly if I forget, but I wanted to make this simpler.
If I could avoid it, I didn’t want to put virtualenv
in my start-up scripts – I’d prefer nothing too complex in there, in case they start causing login problems. virtualenv
depends on a directory that gets periodically deleted and rebuilt – it might not be present and correct at login time.
I considered if I could simply turn off the need for keepalives, so the session could continue even after 18 hours of silence, but the TCP connection would be broken too, right?
Can I tell Linux to re-establish an SSH session, even if after the TCP connection is lost? I couldn’t find a way.
I came to the screen
command, which had been recommended to me before, and I always shied away from as it appeared to be a whole IDE just to control a terminal-shell. The last thing I want to learn is another bloody set of keyboard shortcuts for a command line tool.
Its big advantage is that it spawns a long-running process, that you can reconnect to. If you get disconnected, simply log in and run screen -R
, and you will back to exactly where you were.
screen -d -RR
, because it is idempotent. Otherwise, I was discovering I had many screen processes running at the same time. More precisely, I run !scr
to avoid getting the options confused again.The trouble is that it has a few disadvantages too. But the one that kills me is that it confuses PuTTY’s history buffer.
If I run my unit-tests, I get about 300 lines of output – each line includes the test suite and the word “OK” in green. That’s if they all pass. If any fail, the output is much longer, and includes some choice words in red. So when I run my tests, I come back to check the output, only to find that all but the last few lines have been forgotten by the screen command.
I can’t tell if the tests have all passed, so I have to run the tests again, this time piping through less
or more
– both of which handle the colour-coded text badly. (The less
command converts them to visible characters, the more
command double-spaces the lines.)
Apparently the screen command includes the idea of scrolling back through a “scrollback buffer”, but not by using my scroll-wheel! By learning some arcane new commands – not even emacs-like, but vi-like.
Today, I lost the results of my tests, again, and wasted about 10 minutes with a looming deadline.
I have decided to abandon screen
, and am returning to having to re-login each day, with any long running processes killed unless I thought to nohup
them.
My requirements are not unusual. I am a developer with a need, and if Linux is good at anything, it is good at having met those sorts of needs. I wonder where I am going wrong.
Comment by Aristotle Pagaltzis on November 2, 2011
Try
dtach
instead. It does far less thanscreen
, in particular, it has no terminal emulation. If you lose the connection, whatever was previously on screen is lost – if you need it, you have to arrange to save it. To me that is a feature. What it does do is keep a process alive and allow you to reattach to its output – which is all I need. This specifically ensures that there is no difference to terminal behaviour with or withoutdtach
– whether that concerns scrollback, charsets/encodings, or anything else.You can also ask
less
to pass terminal escapes through using the-R
switch. (There are also other switches to change its exact behaviour. Try usingman
on it sometime, that’s a pretty cool command. 😉 (Not always. I know too well.))Comment by Alastair on November 2, 2011
reptyr might also fit your needs.
Haven’t tried it myself, though. I persist with screen. I found it (screen) a lot easier to use after rebinding the meta key to backtick. But yes the scrollback buffer is still weird.
Comment by Sunny Kalsi on November 2, 2011
Use a mac I hear there really user friendly.
Comment by Alex on December 6, 2011
Have you tried using http://www.bitvise.com/tunnelier ?
Comment by Alex on May 14, 2012
This might be worth a look, if you’re still having this issue – http://mosh.mit.edu/
“Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.
Mosh is a replacement for SSH. It’s more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.”