2

Every time I connect to my Ubuntu 17.10 machine with byobu-enable turned on, I get a new "session" rather than it reusing my existing sessions.

On connect:

Byobu sessions...

  1. tmux: foo: 3 windows (created Sun Jan 28 10:23:59 2018) [204x53] (group foo)
  2. tmux: ba: 1 windows (created Sun Jan 28 10:24:16 2018) [204x53]
  3. Create a new Byobu session (tmux)
  4. Run a shell without Byobu (/bin/bash)

Upon selecting one, say (1), I am dumped to a byobu session named e.g. _foo-20462

$ byobu list-session
_foo-20462: 4 windows (created Sun Jan 28 10:42:20 2018) [204x53] (group foo)
foo: 4 windows (created Sun Jan 28 10:23:59 2018) [204x53] (group foo)
bar: 1 windows (created Sun Jan 28 10:24:16 2018) [204x53]

The odd thing is that _foo-20462 appears to be an exact replica of the "foo" session. The only way I can figure out to kill these is byobu kill-session -t _foo-20462, but I figure there must be a way to disable this behavior, as it was not the same in prior versions of Ubuntu.

Paul Gear
  • 3,938
  • 15
  • 36
djmarcin
  • 23
  • 4
  • fixed byobu 5.125. https://github.com/dustinkirkland/byobu/commit/755c0e9f28b3f8ee57d9c7fc166f0bcbe96577db https://github.com/dustinkirkland/byobu/blob/c4136ebfe970c31a785fb87468fa08ab7fd7039e/debian/changelog#L11 – gs1 Jul 23 '18 at 06:38
  • Thank you @gs1! My use case is to have multiple users connect to an SSH server independently and work in separate tabs. Having a separate session for each client is a desirable feature, not a bug. Restore old behavior with `touch ~/.byobu/.reuse-session`. – dragon Jun 13 '20 at 20:42

1 Answers1

1

I had the same problem and found a fix. I created an issue about this:
https://bugs.launchpad.net/byobu/+bug/1750430

I put on my detective hat and managed to fix it.

TL;DR - Either call tmux directly or revert a change in Byobu's select-session.py.

Running a plain tmux command attaches to the first session, so this is probably the easiest "fix" for this (the oddly named sessions are only created with the tmux backend, not with screen).

However, you can fix this for Byobu, too.

man byobu revealed that the part of Byobu that's responsible for selecting the session is byobu-select-session.

which byobu-select-session directed me to /usr/bin/byobu-select-session, which in turn calls /usr/libexec/byobu/include/select-session.py. These paths may be different for you (I'm on Fedora).

The line in select-session.py that creates and names the session is this one (in the function attach_session()):

os.execvp("tmux", ["tmux", "-2", "new-session", "-t", session_name, "-s", "_%s-%i" % (session_name, os.getpid())])

So, Byobu intentionally creates a session named _%s-%i, where %s is the session name and %i is the PID.

Looking into the Git blame for the line shows this commit:
https://github.com/dustinkirkland/byobu/commit/c0050ac51ee8accc3eb35862483bc40b19e3c269

Reverting the line fixes the issue:

os.execvp("tmux", ["tmux", "-2", "attach", "-t", session_name])

...but probably also removes support for "tmux grouped sessions", but I'm not entirely certain what they're used for, and I can live without them.

Kankaristo
  • 128
  • 1
  • 5
  • Thanks, I had fixed this a similar way and answered this other question without remembering to update this one! https://superuser.com/questions/1282214/reattaching-byobu-session-creates-group-0/1291236?noredirect=1#comment1912146_1291236. It's not clear to me whether attach or new-session -A is the correct behavior here, but reverting the commit is a pretty strong signal it should be attach. :) – djmarcin Feb 20 '18 at 23:20