Upon startup, Resurrect is overwriting prior last symlink file with a "blank" layout

[Blake-LeBlanc]

Hello!

For some reason, tmux-resurrect will often create a new tmux_resurrect file immediately upon startup and update the last symlink point to that new file. To fix this, I have to go in an manually update the symlink to point to a prior tmux_resurrect file.

At first I thought it might have something to do with tmux-continuum, which I had used previously, but I do NOT currently have tmux-continuum installed on the system.

In my .tmux.conf settings, I have Save/Restore set to manual keybindings.

Any ideas how to troubleshoot what may be causing this to happen? Thank you in advance for any pointers and thank you for your great plugin!

UPDATE: I should clarify that this does not happen every time I start tmux. For example, it's been a few days since it happened before this morning.

Here are the contents of the "last" file:

pane    0   1   :bash   1   :*  1   :/home/linux    1   bash    :
window  0   1   1   :*  b25d,80x24,0,0,0
state       

As you'll see, this matches the most recent tmux_resurrect file that was created somehow: tmux_resurrect_20190117T065500.txt

However, the prior layout that was manually saved, is what the "last" file is supposed to point to and is the one I would manually restore from: tmux_resurrect_20190114T092243.txt

Here is a copy of my .tmux.conf file, renamed to a supported .txt file for upload purposes: tmux_conf.txt

[LucasPickering]

I'm also having this issue. Have you found a solution/workaround for it?

[cyniphile]

same. Kinda destroys the whole purpose of the plugin.

[Blake-LeBlanc]

Hi @LucasPickering ! I have not managed to fix it yet, though I can't say I would know where to even start...

Something I recently noticed, though, is that I will sometimes find a newly created tmux_resurrect file with a new "last" symlink even after just launching my terminal, without ever starting tmux or anything.

This is very weird...

[bruno-]

Well tmux-resurrect doesn't perform automatic behavior on its own. My hunch is this is related to tmux-continuum plugin which triggers periodic saves automatically.

[cyniphile]

@bruno- I'm getting this issue even if I prefix, c-s and immediately kill the server, so I don't think continuum has any chance to overwrite in that case.

[Blake-LeBlanc]

Well tmux-resurrect doesn't perform automatic behavior on its own. My hunch is this is related to tmux-continuum plugin which triggers periodic saves automatically.

Yes, that's what I suspected too, though I've double and triple checked that everything related to tmux-continuum are not present on the system or active in my .tmux.conf.

[Blake-LeBlanc]

@LucasPickering So far I'm one week into having a "hassle free" tmux-resurrect experience. Thought I'd share with you something I noticed, maybe it will help on your end? Here's a short rundown...

I briefly switched over to a tmux session management tool called tmuxp. In the process, I also purged my system of anything tmux-resurrect or tmux-continuum related. After doing so, whenever I pushed up my new dotfiles setup, one of the updates it caught was a change to [a supposedly orphaned?] tmux-continuum plugin directory within .tmux.

Since then, I've switched back over to tmux-resurrect and haven't experienced any rogue .last symlink creation issues. My guess is that my laptop may have had some remnants of various files and directories that existed prior to my updating the associated .gitignore file to exclude all tmux related plugins.

Maybe something like that has happened on your end?

I'm going to keep this ticket open in the meantime, if I go another week without incident on either of my systems, then I will close it out :)

[Blake-LeBlanc]

@LucasPickering So far I'm one week into having a "hassle free" tmux-resurrect experience. Thought I'd share with you something I noticed, maybe it will help on your end? Here's a short rundown...

I briefly switched over to a tmux session management tool called tmuxp. In the process, I also purged my system of anything tmux-resurrect or tmux-continuum related. After doing so, whenever I pushed up my new dotfiles setup, one of the updates it caught was a change to [a supposedly orphaned?] tmux-continuum plugin directory within .tmux.

Since then, I've switched back over to tmux-resurrect and haven't experienced any rogue .last symlink creation issues. My guess is that my laptop may have had some remnants of various files and directories that existed prior to my updating the associated .gitignore file to exclude all tmux related plugins.

Maybe something like that has happened on your end?

I'm going to keep this ticket open in the meantime, if I go another week without incident on either of my systems, then I will close it out :)

Quick update! Since this post, new .tmux-resurrect files and the .last symlink file have been created and overwritten four more times.

So I will keep this issue open.

And like you said @bruno- , our beloved tmux-resurrect should not be doing anything on its own, so I'm at a complete loss for why this is happening... From what I can tell, my startup procedure is the same each time; there seems to be no workflow difference when it does do a "rogue save" versus when it does not. It's very strange!

[wallace11]

Is there any update with this issue? I've got two Raspberry Pies running the exact same setup with tmux 3.1b, automatic start with systemd user module (created by continuum plugin). One of them is restoring flawlessly on boot, the other always resets the last saved session upon restoration and symlinks last to a text file that looks like this:

tmux_resurrect_20200601T152757.txt

state__

Plugin config is as follows:

set -g @continuum-boot 'on' 
set -g @continuum-restore 'on' 
set -g @resurrect-capture-pane-contents 'on' 
set -g @resurrect-processes 'nvim' 

I've checked, double checked and triple checked the environments, plugin versions, systemd module, etc. My only guess it that the pi that doesn't restore properly has a slower boot time.