I've been using this for a few months, since for some reason my work Macbook really likes to crash when it goes into sleep mode (have a feeling it's related to our Vagrant/VMWare setup, but haven't had a chance to investigate). It works better than any similar tmux plugin I've tried, and is dead-simple to use.
I particularly like that there's a "whitelist" of which running commands it will restore, so I can e.g. restore both VIM sessions and my Webpack watchers when I restore my session.
If you're on OS X Yosemite, the "sleep wake failure" problem is a well-known issue that is (probably) not hardware-related. I have it, my colleagues (some of whom have brand new machines) have it, and it's probably what you are affected by.
The symptom is that the machine will frequently reboot instead of coming out of sleep. From the looks of things, it's related to the 70-minute sleep-to-standby setting (where the machine will turn itself off), which can be changed with "pmset".
Considering that I recently ran home with a rapidly flattening battery - precisely so that I would not lost my session - I am very pleased to find this here :D
When battery gets low enough, a sleeping MacBook [Pro] will actually wake up from sleep and hibernate to disk all by itself.
(terminology: 'sleep' is suspend to RAM, requires battery to keep active. 'hibernate' is suspend to disk, no battery required after RAM copied to HD—obviously requires enough HD space to run the persistence.)
Not only that, but they do it when the lid is first closed. That way, if it dies in an hour due to a low battery... oh well. (This is also why the more memory you have, the longer it may take for the laptop to go to sleep after closing the lid.)
My experience with my Macbook is that around 20% battery, it just dies. No sleep, no hibernate, it just goes completely dark and when I plug it back in it has to boot from scratch.
Sounds like you have a bad battery or something like that, which is causing the battery meter to be inaccurate and is thus interfering with the rest of the process. To safely sleep/hibernate your machine the system has to have a pretty good idea of just how much energy is left in the battery, since it has to initiate the process before the battery goes completely flat. On a properly working machine, you should get all the way down to 0%, and then it will forcibly sleep if you don't do it yourself.
Have you tried an SMC reset? That's the low-level whatnot that controls the battery, and sometimes it can get confused.
I tried an SMC reset today, and it changed nothing. It still just dies right around 20%. (At least, I think I reset the SMC. There wasn't any obvious feedback confirming that I had done so.)
Yeah, the SMC reset procedure is pretty opaque. Sounds like you're probably at the point of needing a repair. Hope you're in warranty, although given how these things go I imagine you're probably not.
Nah, I've had it a few years, so it's out of warranty. I'll probably have to replace the battery eventually. I don't mind if the battery's capacity is decreasing, I just want it to auto-sleep before the battery dies. Maybe there's a way to set the auto-sleep threshold to 25% or something?
That's definitely a battery problem. I had the same issue after a few years, got the battery replaced and now it works as you'd expect. Of course, the batteries aren't cheap, so it depends on how annoying you find it :) I lived with it for about a year.
I love this plugin. Usually, my mac stays online for days and even weeks, but any time I go down (or for some certain software updates when I have to restart it), it really sucks to lose all your environmental setup.
I combine it with a few lines of code in my ~/.zshrc to automatically enter the virtualenv for the current directory. Works out really nice! :)
Been using tmux resurrect for awhile now and I love it...one thing occurs to me though: does anyone have a hack to automatically save my tmux session on disconnect?
Edit: ahha, not exactly what I asked for, but linked on the tmux-resurrect page is tmux-continuum, automatic saving of tmux sessions. Perfect for me.
Wait... what? That's the whole point of tmux. As far as I know there's no such thing as 'saving'. They're automatically saved. Unless you're on a shared computer? If so... here's a solution I wrote up a while ago:
---
title: Tmux on a shared server
---
Normally, tmux stores its session sockets in the /tmp directory. This
is bad news when trying to run tmux on a shared computer (e.g. shared
compute nodes) since the tmp directory is probably cleared on every
login. To get around this tmux offers a way to store session sockets
in alternative locations. How to use this isn't entirely clear in the
man page though, so I'll outline it here. First, I'll create a
directory to store the socket with ``mkdir ~/.tmux.socket'`{.bash}.
Tmux stores new session sockets in the tmp directory so we must change
that when we start tmux:
TMPDIR=~/.tmux.socket tmux
and to attach to this socket we use the `-S`{.bash} option and glob to
the socket (defaulted to be named `default`{.bash})
tmux -S ~/.tmux.socket/*/default attach
Here are some aliases to put into your shell config file to help:
alias tmux-start="TMPDIR=~/.tmux.socket tmux"
alias tmux-attach="tmux -S ~/.tmux.socket/*/default attach"
I wrote a far more basic zsh config script that integrates with OSX's Terminal.app window restoration to restore the current working directory in each tab after quit / relaunch. Between that and browser tab restoration on reboot, I don't mind the occasional restart any more.
I gave up on tmux on my Mac, as I mainly used it with teamocil to have saved layouts of panes and commands, but I never disconnected from it. I found quite a few people use it this way.
I wrote iTermocil[2] to replicate the functionality of teamocil natively in iTerm2, so I could have all the upsides (from my POV) but keep native UI elements etc.
Simple because I came across teamocil first, as someone recommended it to me. It is actually teamocil that led me to tmux!
I have since come across tmuxinator, which is almost identical, but from my reading of tmuxinators docs it seems it is more flexible in how you can configure it.
Will have a look, thanks.
I was dreaming of something that could restore tmux sessions, along with its ssh connections, and the vim inside the ssh :D seems like christmas is not for today.
You could use a bastion host to run the tmux. If your client machine were to disconnect/reboot, the bastion host would keep the sessions open. You'd just need to login to it and re-attach tmux.
You don't need anything beside regular tmux for that, since if your computer crashes but not the remote host, and if you were using tmux on the remote host, the tmux session will still be open, just ssh again and "tmux -a" and you'll jump back into the tmux session exactly where you left it.
Mosh is awesome and totally worth the 30 seconds it takes to install it. As far as security:
Q: What is Mosh's security track record so far?
Mosh 1.0 was released in March 2012. As of the release of Mosh 1.2.5 in July 2015, as far as the developers are aware:
In the last three years, no security vulnerabilities of any kind (major or minor) have been reported in Mosh.
No major security vulnerabilities have ever been reported in Mosh. We define major security vulnerabilities to include privilege escalation, remote code execution, denial-of-service by a third party, etc.
Two denial-of-service issues were discovered and fixed in releases in 2012. One issue allowed a mosh-server to cause the mosh-client to spend excess CPU (CVE-2012-2385, fixed in Mosh 1.2.1, released May 2012). Another issue allowed the server host to cause the mosh-client to send UDP datagrams to an incorrect address, foiling its attempt to connect (fixed in Mosh 1.2.2, released July 2012).
Q: How does Mosh's security compare with SSH's?
We think that Mosh's conservative design means that its attack surface compares favorably with more-complicated systems like OpenSSL and OpenSSH. Mosh's track record has so far borne this out. Ultimately, however, only time will tell when the first serious security vulnerability is discovered in Mosh—either because it was there all along or because it was added inadvertently in development. OpenSSH and OpenSSL have had more vulnerabilities, but they have also been released longer and are more prevalent.
In one concrete respect, the Mosh protocol is more secure than SSH's: SSH relies on unauthenticated TCP to carry the contents of the secure stream. That means that an attacker can end an SSH connection with a single phony "RST" segment. By contrast, Mosh applies its security at a different layer (authenticating every datagram), so an attacker cannot end a Mosh session unless the attacker can continuously prevent packets from reaching the other side. A transient attacker can cause only a transient user-visible outage; once the attacker goes away, Mosh will resume the session.
However, in typical usage, Mosh relies on SSH to exchange keys at the beginning of a session, so Mosh will inherit the weaknesses of SSH—at least insofar as they affect the brief SSH session that is used to set up a long-running Mosh session.
It's a matter of semantics. Parent is correct that mosh requires SSH to function. From the same page you linked:
> Mosh doesn't listen on network ports or authenticate users. The mosh client logs in to the server via SSH, and users present the same credentials (e.g., password, public key) as before. Then Mosh runs the mosh-server remotely and connects to it over UDP.
I know I will continue to be down voted BUT you need to get into politics. Because you are arguing the whole sentence "MOSH is a replacement for SSH." Means It is NOT a replacement? Argument is it has SSH as a requirement so "technically" it isn't replacing SSH, even though based on precise facts it actually does kill SSH and replace it when it is used? The authors of MUSH clearly make a one sentence statement of purpose to "replace SSH." Your statement "It isn't a replacement for SSH." is more correct?
It does have SSH required but it uses it for a limited authorization and than SSH on TCP is abandoned once the connection established and the connection is handed over (Replaced) to a MOSH UDP with encryption that is totally independent from SSH.
Makes me crazy that "technically" always means I will say the EXACT opposite of the statement and say that my opposite is more accurate than the stated statement.
This statement is technically true based on facts and declaration of the authors. MOSH is a mobile shell that replaces SSH connections. It doesn't matter that SSH is there the SSH connection is replaced with a UDP MOSH connection. Does it in literal sense in its actions.
I made that "technically speaking" statement in the context of "I don't feel like installing a not well established ssh server replacement on hosts at work". I thought, maybe Galanwe has concerns about security and the fact that mosh builds on ssh instead of replacing it might be a counter argument.
Mosh is a replacement for ssh (the client), but not for sshd, as it relies on it to make a connection. OpenSSH also is not meant to be replaced, which also has not been claimed in your link.
Please pay attention to semantics while fencing with words.
Joe - you changed the very words from SSH to sshd, sshd is just the server side of SSH really what does that matter at all? What part of "Mosh is a replacement for ssh (the client), but not for sshd, as it relies on it to make a connection" Is any different than my whole previous post?
Read my statement on SSH being replaced. The sshd connection is actually totally and completely replaced with a UDP MISH connection and sshd no longer works after the connection is authorization. So in action SSH connection is shut down and handed over to MOSH (AKA Replaces the Connection) Also it is so you never use SSH for your work except to be authorized by your keys.
>OpenSSH also is not meant to be replaced, which also has not been claimed in your link
My Link - The official website for MOSH. The only statement is that they think MOSH is more secure than OpenSSL and OpenSSH. But yes it replaces OpenSSH and SSH. It replaces the very connection it makes and it replaces SSH or OpenSSH with MOSH to handle EVERYTHING except that initial handshake authorization.
Please Quote your source for "which also has not been claimed in your link"
I say look at the mirror. Joe the statement is 100% true MOSH is a replacement for SSH in purpose, programming and in practice. Where is it okay to say that MOSH is a replacement for SSH is wrong in any sense besides it is a requirement?
I read that, but as a rather heavy user of tmuxinator, I wouldn't really want to have all my projects running in the background at all times. I like that with tmuxinator, I can just start up the project(s) I'm currently working on, and leave the rest idle.
I am going to try out tmux-resurrect, but it's value to me would be mostly for ad-hoc tmux sessions; I think I'll still set up dedicated tmuxinator configs for each of my longer term projects.
I particularly like that there's a "whitelist" of which running commands it will restore, so I can e.g. restore both VIM sessions and my Webpack watchers when I restore my session.