Repair SSH, GPG and D-Bus Variables After Reattaching Byobu

You will finish with the session environment in your current shell refreshed from the attached Byobu session. That can restore access to GPG agent, D-Bus, SSH agent and related session sockets after you reattach. The installed command is from Byobu 6.11, package version 6.11-0ubuntu1.1.

Allow about ten minutes. You need Byobu already installed and an interactive shell inside, or attached to, the relevant Byobu session. This procedure changes environment variables in the shell where you source the file. It does not need sudo, restart a service or edit persistent configuration.

1. Check the installed file and package

Confirm that the command resolves to the Byobu installation you intend to use:

$ command -v byobu-reconnect-sockets
/usr/bin/byobu-reconnect-sockets
$ dpkg-query -W -f='${Package} ${Version}\n' byobu
byobu 6.11-0ubuntu1.1

Your path or package version may differ. The important check is that the file belongs to the same Byobu installation as the session you are repairing. If command -v prints nothing, stop and install or select the correct Byobu package through your normal system administration process.

2. Source the file in the current shell

Use the POSIX dot command. The space after the dot is required:

. /usr/bin/byobu-reconnect-sockets

In Bash, this equivalent spelling is also clear:

source /usr/bin/byobu-reconnect-sockets

There is no normal success message. A successful source operation is usually quiet. The installed script checks for an interactive shell, reads the Byobu backend environment, imports values from the current tmux or screen session, then refreshes values held in the GPG agent, D-Bus session and Byobu socket files. It exports the refreshed values into this shell and sends relevant values back to the backend.

Check the status immediately after sourcing:

$ . /usr/bin/byobu-reconnect-sockets
$ printf 'source status: %s\n' "$?"
source status: 0

The status belongs to the source command immediately before printf. If you run another command first, you have lost the useful status.

3. Verify the variables you actually need

Print names and values without changing them:

printf 'DBUS_SESSION_BUS_ADDRESS=%s\n' "${DBUS_SESSION_BUS_ADDRESS-unset}"
printf 'GPG_AGENT_INFO=%s\n' "${GPG_AGENT_INFO-unset}"
printf 'SSH_AUTH_SOCK=%s\n' "${SSH_AUTH_SOCK-unset}"
printf 'SESSION_MANAGER=%s\n' "${SESSION_MANAGER-unset}"

Expect values to be host- and session-specific. A variable can legitimately be unset: the corresponding agent or session service may not be running, or the application may use a different mechanism. Do not paste these values into a ticket or public log. Socket paths and session addresses reveal local details, and agent-related values can be security-sensitive.

For a practical GPG check, ask GPG to show its configured home and key listing:

$ gpgconf --list-dirs homedir
/home/USER/.gnupg
$ gpg --list-secret-keys --keyid-format=long
sec   ...

The exact key output depends on the account. If the command reports that it cannot connect to an agent, source the Byobu file again inside the correct session and inspect GPG_AGENT_INFO. Do not treat a successful variable refresh as proof that every agent or application is healthy.

4. Understand the execution trap

This file is shell code intended to be read into your current shell. Executing it as a child process cannot update the parent environment:

$ byobu-reconnect-sockets

ERROR: You must source this file, rather than execute it.
  . /usr/bin/byobu-reconnect-sockets

The command exits non-zero in this case. That message is the expected guard, not an indication that the session itself is broken. The same rule applies if you invoke it by an absolute path. Use . or source, and run it in the shell from which you will launch the application that needs the variables.

A new shell cannot repair the old shell's environment. For example, sh -c '. /usr/bin/byobu-reconnect-sockets' may source the file in the child and then discard its exports when the child exits. Source it directly at your prompt instead.

5. Know what the script reads

The local script reads $HOME/.byoburc when present, then uses Byobu's common helpers. For the active backend it reads values from tmux showenv, or asks screen to write environment assignments into a temporary file. It then looks for the newest GPG agent information under $HOME/.gnupg/gpg-agent-info-*, the newest D-Bus session file under $HOME/.dbus/session-bus/*, and a Byobu sockets file at $BYOBU_RUN_DIR/sockets.

Those files are sourced as shell input. Security boundary: only use the installed script with a home directory, Byobu session and backend that you trust. Do not point HOME, BYOBU_PREFIX or BYOBU_RUN_DIR at files supplied by another user, copied from an untrusted machine or obtained from a forum. Sourcing shell files can execute commands, so inspect unusual files before using them. This is a read-and-refresh operation, but it is not a data-only parser.

6. Recover from a failed refresh

First confirm that the shell is interactive and that you are inside the intended Byobu session:

case $- in
    *i*) printf '%s\n' 'interactive shell' ;;
    *)   printf '%s\n' 'not interactive: source this at the real prompt' >&2 ;;
esac
printf 'backend: %s\n' "${BYOBU_BACKEND-unset}"
printf 'run directory: %s\n' "${BYOBU_RUN_DIR-unset}"

The installed backend is normally tmux or screen. If the backend is empty or points at a session you did not expect, do not invent a value and do not run the script with sudo. Reattach to the correct Byobu session, or ask the administrator who owns it how it was started.

Check the source files without sourcing them:

ls -l "$HOME/.byoburc" "$BYOBU_RUN_DIR/sockets" 2>/dev/null
find "$HOME/.gnupg" "$HOME/.dbus/session-bus" -maxdepth 1 -type f -print 2>/dev/null

No output can simply mean that a file is not used on this host. A permission error, unexpected owner or file copied from another account is a reason to stop. Do not create replacement socket files by hand. Let Byobu, D-Bus or GPG create their own state, then source the file again.