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

byobu-reconnect-sockets fixes the moment gpg-agent, ssh-agent and D-Bus all go quiet the instant you reattach a Byobu session over SSH. Source it in the shell where you want those variables restored, and the whole check takes about ten minutes. The installed command is from Byobu 6.11, package version 6.11-0ubuntu1.1.

You need Byobu already installed and an interactive shell inside, or attached to, the session you are repairing. This only changes environment variables in the shell where you source the file: no sudo, no service restart, no persistent configuration edit.

1. Check the installed file and package

Confirm that the command resolves to the Byobu installation you actually mean 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 check that matters 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, do not execute it

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

. /usr/bin/byobu-reconnect-sockets

In Bash, this reads exactly the same:

source /usr/bin/byobu-reconnect-sockets

A successful run is quiet: no banner, no summary. 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, before anything else can overwrite it:

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

That status belongs to the source command directly above it. Run one more command first and you have lost the useful result.

3. Verify the variables you actually need

Print names and values without changing anything:

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 host and session specific values. Do not compare them against another machine's output.
• A blank variable can be entirely normal. The matching agent or session service may simply not be running, or the application may use a different mechanism.
• Keep these out of tickets and logs. Socket paths and session addresses reveal local details, and agent values can be security sensitive.

For a working GPG check rather than an empty variable, ask GPG directly:

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

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

4. Never execute this file as a child process

This file is shell code meant to run inside your current shell. Execute it as a child process instead, and the parent shell never sees the update:

$ byobu-reconnect-sockets

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

The command exits non-zero here, and that is the guard doing its job, not a sign the session itself is broken. The same rule applies to an absolute path invocation. Use . or source, and run it in the exact shell that will launch the application needing the variables.

A child shell cannot repair its parent's environment. For example, sh -c '. /usr/bin/byobu-reconnect-sockets' sources the file in the child, then throws its exports away the moment that child exits. Source it directly at your prompt instead.

5. Know what the script actually reads

The local script reads $HOME/.byoburc when present, then falls back to Byobu's common helpers. For the active backend it reads values from tmux showenv, or has screen 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.

6. Recover from a failed refresh

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

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 it is empty, or points at a session you did not expect, do not invent a value and do not reach for sudo. Reattach to the correct Byobu session, or ask whoever 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 a file is not used on this host. A permission error, an unexpected owner, or a file copied from another account is a reason to stop, not push through. Do not create replacement socket files by hand: let Byobu, D-Bus or GPG create their own state, then source the file again.