Tmux Resurrect – Persists tmux environment across system restarts | Hacker News Reader

Tmux Resurrect – Persists tmux environment across system restarts

github.com

231 pointsandars55 comments

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

why not hibernate?

http://www.sickenger.com/2013/02/hibernate-just-stop-it/

<jk>

Mac. Does sleep when battery flat, rather than "die" completely - but how long do you trust it for? Knowing Sod's Law, I opted for the run.

Newer Macs will save the memory to nonvolatile storage so they can withstand total power loss. The question of trustworthiness remains, though.

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.

Yea, I've never had issues like that, and I've used Mac's exclusively for since they came out with the unibody.

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?

It's definitely a hardware issue. I owned two Macbooks and both went to sleep/hibernate when battery reached 0%.

My MBP doesn't die even at 3%, it just goes to the "hibernate" state.

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.

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

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

Wondering if that is Pro specific, or applies of Air too.

It applies to Airs too. All customisable through pmset - https://developer.apple.com/library/mac/documentation/Darwin...

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! :)

there's a oh-my-zsh plugin for that

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"

He probably means saving on computer shutdown or reboot.

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.

https://gist.github.com/pcl/f2c6a6f6f193400eeaa6

I don't have a .zsh.d folder but a .oh-my-zsh folder

Where do I put your script?

You should be able to drop it in ~/.oh-my-zsh/custom and have it run automatically upon terminal login.

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.

[1] https://github.com/TomAnthony/itermocil

I didn't know about Teamocil, I use Tmuxinator for the same purpose. The latter seems to have more stars on GH, any reason why prefer the former?

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.

I'm adding tmuxinator support to iTermocil. :)

Brilliant, looking forward!

Is it also able to restore ssh session? Like, host and working directory at least?

I doubt it, since the TCP connection will probably have timed out. Try using mosh: https://mosh.mit.edu/

mosh is nice, but I don't feel like installing a not well established ssh server replacement on hosts at work.

Why?

Technically, it is not a replacement, since it requires a ssh server for authentication.

> Mosh is a replacement for SSH. (https://mosh.mit.edu) First sentence in second paragraph.

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.

"Technically Speaking" = Political Double Talk

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.

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.

My Statement: MOSH is a replacement for SSH

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

But it does completely replace it EXCEPT for SSH connection.

1) SSH makes the TCP connection

2) MOSH starts a UDP Connection

3) MOSH kills the SSH TCP Connection and there is no ssh processes running anymore.

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.

By default it only restores a program that is whitelisted, such as vim, man, etc. You could, I guess, tell it to also restore ssh sessions. Here's a guide on how to do that: https://github.com/tmux-plugins/tmux-resurrect/blob/master/d...

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.

Has anyone here ported from Tmuxinator to Tmux Resurrect? Was it a Success?

Just in case you missed it, there's a guide how to migrate from tmuxinator to tmux-resurrect:

https://github.com/tmux-plugins/tmux-resurrect/blob/master/d...

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.

Thanks for this!

I've done something horrible in the past when I knew about coming rolling power outages - snapshoting virtual box. It worked but was sort of annoying.

This is the greatest thing since ... tmux.

If only @resurrect-save-zsh-history was implemented.

What I don't like is that you have to manually save/restore every time.

There is tmux-continuum that works with resurrect to automate saving/restoring.

https://github.com/tmux-plugins/tmux-continuum

Reply on news.ycombinator.com