search

tmux-plugins / tmux-continuum

Continuous saving of tmux environment. Automatic restore when tmux is started. Automatic tmux start when computer is turned on.
MIT License
3.31k stars 149 forks source link

Tmux exits after started with @continuum-restore 'on' #110

Closed twnaing closed 1 year ago

twnaing commented 2 years ago

I am running tmux 3.3a with the following minimal configuration.

# change TMUX plugin manager path
set-environment -g TMUX_PLUGIN_MANAGER_PATH '~/.tmux/plugins/'

# set path
set-environment -g PATH '/usr/local/bin:/bin:/usr/bin'

set -g @continuum-boot 'on'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '5';

# list of plugins
set -g @tpm_plugins '              \
    tmux-plugins/tpm               \
    tmux-plugins/tmux-resurrect    \
    tmux-plugins/tmux-continuum    \
'

# Initialize tmux plugin manager
# NOTE: KEEP THIS LINE AT THE VERY BOTTOM OF tmux.conf
run -b '~/.tmux/plugins/tpm/tpm'

On starting with user systemd, I get the followings in journalctl

$ journalctl --user -u tmux
Jun 29 13:49:16 manjaro-pc systemd[4016]: Starting tmux default session (detached)...
Jun 29 13:49:16 manjaro-pc systemd[4016]: Started tmux default session (detached).
Jun 29 13:49:18 manjaro-pc save.sh[635829]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635875]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635880]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635897]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635902]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635905]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635908]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635912]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635914]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635921]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635923]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635924]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635925]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635926]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc systemd[4016]: tmux.service: Control process exited, code=exited, status=1/FAILURE
Jun 29 13:49:18 manjaro-pc save.sh[635868]: Terminated
Jun 29 13:49:18 manjaro-pc save.sh[635927]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc systemd[4016]: tmux.service: Failed with result 'exit-code'.

Manual starting of tmux new-session -d and tmux ls shows

no server running on /tmp/tmux-1000/default

If I remove the set -g @continuum-restore 'on', the tmux server starts. Attached are the output from tmux -vvvv new-sesion -d

tmux-client-837926.log tmux-out-837928.log tmux-server-837928.log

iAmMrinal0 commented 2 years ago

I noticed this issue today. I had resurrect, continuum, and copycat and had to try with each of them separately and faced this.

reductist commented 2 years ago

Same issue on MacOS (tmux 3.2a). Resolved after commenting out set -g default-command "reattach-to-user-namespace -l $SHELL" in my .tmux.conf.

bjornfor commented 1 year ago

I'm affected as well, and similarly to OP I can "fix it" by commenting out set -g @continuum-restore 'on'.

I see this backtrace in journalctl --user -f:

Nov 29 18:10:44 bf-laptop systemd-coredump[505739]: [🡕] Process 504232 (tmux: server) of user 1000 dumped core.

                                                    Module linux-vdso.so.1 with build-id 30f1c5e3564573eae5ca9c23fc4657ee37d04afd
                                                    Module libpthread.so.0 with build-id 85431f01160c3de171d3baeb3f8cf1c9578dc441
                                                    Module libgpg-error.so.0 without build-id.
                                                    Module ld-linux-x86-64.so.2 with build-id db50353a26600bb848b9a5541b1506e0a24cb34b
                                                    Module liblz4.so.1 without build-id.
                                                    Module libzstd.so.1 without build-id.
                                                    Module liblzma.so.5 without build-id.
                                                    Module libgcrypt.so.20 without build-id.
                                                    Module libcap.so.2 without build-id.
                                                    Module libc.so.6 with build-id 2bb226bc600b443958c7566207d0d02f8345e6ea
                                                    Module libresolv.so.2 with build-id 88f3bb8423742b08f89ecabb2800b03d17d06e6c
                                                    Module libm.so.6 with build-id b8454b40db819599169f3a948939aed4b3fc7f82
                                                    Module libevent_core-2.1.so.7 without build-id.
                                                    Module libncursesw.so.6 without build-id.
                                                    Module libutempter.so.0 without build-id.
                                                    Module libsystemd.so.0 without build-id.
                                                    Module tmux without build-id.
                                                    Stack trace of thread 504232:
                                                    #0  0x00007fb1180a297d __strlen_avx2 (libc.so.6 + 0x15d97d)
                                                    #1  0x00007fb117fb277e __vfprintf_internal (libc.so.6 + 0x6d77e)
                                                    #2  0x00007fb117fc29b5 __vasprintf_internal (libc.so.6 + 0x7d9b5)
                                                    #3  0x00000000004910a4 xvasprintf (tmux + 0x910a4)
                                                    #4  0x000000000041ac60 cmdq_error (tmux + 0x1ac60)
                                                    #5  0x000000000041d4c2 cmd_select_layout_exec (tmux + 0x1d4c2)
                                                    #6  0x000000000041a63c cmdq_next (tmux + 0x1a63c)
                                                    #7  0x0000000000464a95 server_loop (tmux + 0x64a95)
                                                    #8  0x0000000000453002 proc_loop (tmux + 0x53002)
                                                    #9  0x00000000004651ec server_start (tmux + 0x651ec)
                                                    #10 0x000000000040b532 client_main (tmux + 0xb532)
                                                    #11 0x000000000040634e main (tmux + 0x634e)
                                                    #12 0x00007fb117f6e24e __libc_start_call_main (libc.so.6 + 0x2924e)
                                                    #13 0x00007fb117f6e309 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29309)
                                                    #14 0x0000000000406705 _start (tmux + 0x6705)
                                                    ELF object binary architecture: AMD x86-64
bjornfor commented 1 year ago

The stack trace is not consistent between runs. I've seen at least 2 different ones.

I wanted to set a breakpoint on cmd_select_layout_exec, because it seemed like an interesting place to look (based on the traceback), but I had problems getting gdb to do that. I played a bit with detach-on-fork, follow-fork-mode and follow-exec-mode settings, but didn't get satisfactory result -- either things hung or never hit the breakpoint. And I'm that lazy that I don't want to manually traverse the fork()'s.

However, I found this suspicious sleep 1 in $prefix/share/tmux-plugins/continuum/scripts/continuum_restore.sh that I increased to sleep 2, and it seemed to fix the problem! However, after more testing, I cannot reproduce the original issue (server exited unexpectedly) anymore. Related, I tried removing the sleep and saw tmux become semi-broken -- it started fine but windows lacked names.

bjornfor commented 1 year ago

Hm, now I seem to have the issue again, and sleep 2 doesn't help (I even tested with sleep 5).

bjornfor commented 1 year ago

I think the problem is old "resurrect" data breaking newer code.

Starting point:

$ tmux
server exited unexpectedly

Now clean up and run again:

$ rm -rf ~/.local/share/tmux/resurrect/
$ tmux 
(successfully running)

I think that ~/.local/share/tmux/resurrect/ isn't the default -- I've configured that myself. However, I confused myself some extra because I also had left-over ~/.tmux/resurrect from before that configuration change, and while debugging this issue I kept playing with the state in ~/.tmux/resurrect instead of my actual state data. Doh!

Based on the traceback, I'd say something has changed in how layouts are named/stored and tmux has bad error handling.

bjornfor commented 1 year ago

@twnaing: I think this can be closed.

jola5 commented 1 year ago

Run into the same issue recently (on arch, with fish+tmux+ressurect+continuum) and removing ressurect data like @bjornfor mentioned here https://github.com/tmux-plugins/tmux-continuum/issues/110#issuecomment-1335060795 fixed this for me as well. Cheers bjornfor!

luchaoqi commented 1 year ago

same error here. rm -rf ~/.local/share/tmux/resurrect/ works may also try chmod 755 ~/.tmux suggested here to restore old resurrect file.

twnaing commented 1 year ago

fixed for me

Nicholas-Autio-Mitchell commented 1 year ago

Removing old resurrect files was also the solution for me, but that included these:

rm -rf ~/.tmux/resurrect

Now auto restore works with these settings:

set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'