tmux-continuum icon indicating copy to clipboard operation
tmux-continuum copied to clipboard

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

Open twnaing opened this issue 2 years ago • 2 comments

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

twnaing avatar Jun 29 '22 07:06 twnaing

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

iAmMrinal0 avatar Jul 27 '22 14:07 iAmMrinal0

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.

reductist avatar Aug 13 '22 03:08 reductist

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 avatar Nov 29 '22 17:11 bjornfor

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 avatar Dec 01 '22 12:12 bjornfor

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

bjornfor avatar Dec 01 '22 12:12 bjornfor

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 avatar Dec 02 '22 10:12 bjornfor

@twnaing: I think this can be closed.

bjornfor avatar Dec 02 '22 10:12 bjornfor

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!

jola5 avatar Mar 15 '23 10:03 jola5

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

luchaoqi avatar May 22 '23 03:05 luchaoqi

fixed for me

twnaing avatar May 24 '23 04:05 twnaing

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'

Nicholas-Autio-Mitchell avatar Jul 12 '23 00:07 Nicholas-Autio-Mitchell