Sometimes I get duplicate sessions

[Eric Zillmann]

Ubuntu 18.04.1 LTS
byobu version 5.125
tmux 2.6

Sometimes I get two sessions with the same content:

(0) - 1: 1 windows (group 1)
(1) └─> 1: server1* (1 panes) "[screen] ezi@myhost: ~"
(2) - 4: 2 windows (group 4) (attached)
(3) ├─> 0: rar- (1 panes) "[screen] ezi@myhost: /var/www"
(4) └─> 1: while* (1 panes) "[screen] ezi@myhost: ~"
(5) - _1-20557: 1 windows (group 1)
(6) └─> 1: server1* (1 panes) "[screen] ezi@myhost: ~"
(7) - _4-28315: 2 windows (group 4)
(8) ├─> 0: rar* (1 panes) "[screen] ezi@myhost: /var/www"
(9) └─> 1: while#- (1 panes) "[screen] ezi@myhost: ~"

I hope the formatting doesn't screw up.

Lines 0 to 4 are almost exactly the sames as 5 to 9 except that the session names(?) are
* 1 vs. _1-20557
* 4 vs. _4-28315

This is not the case on freshly created sessions, only after a while.

[Abdi-Hakin Dirie (aadah)]

> This is not the case on freshly created sessions, only after a while.

I'm able to consistently reproduce this bug.

Context:
- `byobu-enabled` so that Byobu runs on login shells.
- All my shells are login shells.

To re-create this bug, I do the following:

1. Start new session.
   - Optionally, give the session a custom name.
2. Detach from session. This will cause the shell window to close as well.
3. Re-attach to session by starting a new shell.
4. There should be 2 sessions now: NAME and _NAME-INTEGER

[Dustin Kirkland  (kirkland)]

Hmm, I'm not able to reproduce this...

[Leonardo Pereira de Souza Tigre (leonardotigre)]

I'm getting the same issue.

Do not matter if it is a new session or a old one.

To reproduce:
1. Start a new session by typing 'byobu';
2. Then press F6 or Shift + F6 to detach the session;
3. So enter byobu again by typing 'byobu';

It's alwais giving me a duplicated session.

byobu version 5.125
tmux 2.6
Ubuntu 18.04

[Eric Dostie (emd)]

I am able to reproduce this using the steps described above.

byobu 5.125-0ubuntu1
tmux 2.6-3
Ubuntu 18.04.1$ byobu list-sessions
no server running on /tmp/tmux-1000/default

On a fresh reboot (no active tmux sessions), to reproduce:
1. Start a new session by typing 'byobu'.
2. Press F6 to detach the session.
3. Resume session by typing 'byobu'.

I get a duplicate session showing the same state as the existing session.

I noticed that if I detach and resume, I keep getting a duplicate session, but the previous duplicate session is pruned.

Example output:

$ byobu list-sessions
no server running on /tmp/tmux-1000/default
$ byobu
[detached (from session 1)]
$ byobu list-sessions
1: 1 windows (created Mon Aug 20 11:16:12 2018) [148x51]
$ byobu
[detached (from session _1-4285)]
$ byobu list-sessions
1: 1 windows (created Mon Aug 20 11:16:12 2018) [148x51] (group 1)
_1-4285: 1 windows (created Mon Aug 20 11:16:26 2018) [148x51] (group 1)
$ byobu
[detached (from session _1-4463)]
$ byobu list-sessions
1: 1 windows (created Mon Aug 20 11:16:12 2018) [148x51] (group 1)
_1-4463: 1 windows (created Mon Aug 20 11:17:00 2018) [148x51] (group 1)

I hope this helps.

[PabloAB (pabloab777)]

Probably [this is the related AskUbuntu question][1]

  [1]: https://askubuntu.com/q/927187/349837

[PabloAB (pabloab777)]

To reproduce the bug:

- Press F6: Detach session and then logout.

That's it, now you have:

$ tmux ls
1: 3 windows (created Wed Mar 13 20:06:23 2019) [211x58] (group 1)
_1-7845: 3 windows (created Wed Mar 13 22:48:26 2019) [211x58] (group 1) (attached)

Workaround:

- Move to "original" session
- Run: tmux kill-session -t "$(tmux ls | grep _ | tail -1 | cut -f1 -d:)"

$ byobu --version
byobu version 5.125
tmux 2.6

[Federico (illiax)]

This is happening to me aswell . PabloAB possible workaround worked for me.

[Michael Stovenour (mstovenour)]

I have several debian 9 and 10 systems. The debian 9 systems do not exhibit this problem however all of the debian 10 systems are affected. The problem is specific to using non-numeric session names and a change at some point in tmux. Numeric session names are properly culled when starting a new session however if the sessions are renamed to use non-numeric characters then the cull_zombies function no longer matches the zombies.

tmux 2.3-4 always seems to use numeric group names regardless of the actual group name:
ms@debian9:/etc/mail$ dpkg -s tmux | grep Version
Version: 2.3-4

Created two session groups but did not rename either of them:
ms@debian9:/etc/mail$ tmux list-sessions
1: 2 windows (created Sat Oct 3 08:55:48 2020) [142x41] (group 0)
6: 1 windows (created Sat Oct 3 09:05:52 2020) [142x41] (group 1)
_1-8014: 2 windows (created Sat Oct 3 09:06:36 2020) [142x41] (group 0)
_6-8128: 1 windows (created Sat Oct 3 09:06:49 2020) [142x41] (group 1)

Renamed group 6 to foo:
michael@ian:/etc/mail$ tmux list-sessions
1: 2 windows (created Sat Oct 3 08:55:48 2020) [142x41] (group 0)
_1-8014: 2 windows (created Sat Oct 3 09:06:36 2020) [142x41] (group 0)
_foo-8840: 1 windows (created Sat Oct 3 09:10:16 2020) [142x41] (group 1)
foo: 1 windows (created Sat Oct 3 09:08:14 2020) [142x41] (group 1)

You can see that the output of list-sessions still uses (group 1) for the renamed session.

However tmux 2.8-3 has started displaying the renamed group in the list-sessions output:
ms@debian10:~$ dpkg -s tmux | grep Version
Version: 2.8-3

ms@debian10:~$ tmux list-sessions
1: 2 windows (created Sat Oct 3 08:59:12 2020) [121x37] (group 1)
_1-5767: 2 windows (created Sat Oct 3 09:12:11 2020) [121x37] (group 1)
_foo-6268: 1 windows (created Sat Oct 3 09:13:06 2020) [121x37] (group foo)
foo: 1 windows (created Sat Oct 3 09:12:37 2020) [121x37] (group foo)

Here you can see "(group foo)" on the end of the session list

The fix requires a one line change in the cull_zombies function to look for any character, not just integers. I believe this will be backward compatible from my quick tests but YMMV.

ms@debian10:~$ diff /usr/lib/byobu/include/select-session.py select-session.py
105c105
< pattern = "^%s:.+\\((group .+)\\).*$" % session_name
---
> pattern = "^%s:.+\\((group \\d+)\\).*$" % session_name

For now I've manually applied this patch to all my debian 10 systems.

[Michael Stovenour (mstovenour)]

There is another solution to this that prevents byobu from creating the temp sessions in the first place. This solution has a behavior change for byobu that some users may not like. Effectively this causes byobu to reattach to the exact same tmux session each time. If you run one terminal session where you connect, do some work, disconnect, later reconnect, do some more work; then this change will work very well for you. If you like to start byobu from multiple "simultaneous" terminal sessions and attach to the same byobu/tmux session then your terminal sessions will be mirrored; probably not what you wanted. My solution to this new behavior is to ensure that I always select "create new session" when starting byobu simultaneously from an additional terminal session.

--- select-session.py.2 2020-10-03 09:50:21.945316258 -0500
+++ /usr/lib/byobu/include/select-session.py 2020-10-03 09:52:01.926838977 -0500
@@ -131,7 +131,7 @@
        cull_zombies(session_name)
        # must use the binary, not the wrapper!
        if backend == "tmux":
- os.execvp("tmux", ["tmux", "-2", "new-session", "-t", session_name, "-s", "_%s-%i" % (session_name, os.getpid())])
+ os.execvp("tmux", ["tmux", "-2", "new-session", "-A", "-s", session_name])
        else:
                os.execvp("screen", ["screen", "-AOxRR", session_name])

This is a different experience though so play with it for a while to see if you like it.

[m grachten (m-grachten)]

I can reproduce this bug on Ubuntu 18.04.5

> byobu --version
  byobu version 5.125
  tmux 2.6