Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Linux: `gog` runs `dbus-launch` at startup, and `DBUS_SESSION_BUS_ADDRESS=disabled:` skips the file fallback

Open
#1,258 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
60/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
cli

Research direction

Start with internal/secrets/backend.go, especially shouldForceFileBackend around lines 204-206, which only treats an empty DBUS_SESSION_BUS_ADDRESS as 'no bus'. The issue points at 99designs/keyring's kwallet.go and secretservice.go init-time D-Bus connections as the root cause, so check whether lazy backend selection in gogcli can avoid triggering those inits. First reproduce with the script in the issue body, then make auto treat disabled: like a missing bus; done means no dbus-launch on gog --version with GOG_KEYRING_BACKEND=file and auto falling back to file.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:auth-provider impact:crash-loop issue-rating: 🦞 diamond lobster P1
Summary

On headless Linux/WSL2 with no session bus, every gog invocation — even gog --version with GOG_KEYRING_BACKEND=file — can spawn dbus-launch. On our WSL2 host this leaked 575 session dbus-daemon processes, exhausted the inotify instance limit (max_user_instances=128), and left daemons holding temporary HOME directories open so our tooling could not clean them up.

Setting DBUS_SESSION_BUS_ADDRESS=disabled: stops the launches, but auto then no longer falls back to the file backend (it picks pass and fails if the store isn't initialized).

Reproduction

Tested with the official Linux amd64 release v0.46.0 (e0e3cb9c 2026-10-21T05:43:32Z) on WSL2 Linux 6.6.114.1. No Google credentials or network requests are needed. Set GOG_BIN to the absolute path of that release binary. Run in Bash:

GOG_BIN=/absolute/path/to/gog
probe=$(mktemp -d)
mkdir -p "$probe/bin" "$probe/home"
cat > "$probe/bin/dbus-launch" <<'SH'
#!/bin/sh
printf 'launch\n' >> "$PROBE_LOG"
exit 1
SH
chmod +x "$probe/bin/dbus-launch"
: > "$probe/launches.log"

run_gog() {
  env -i PATH="$probe/bin:/usr/bin:/bin" HOME="$probe/home" \
    XDG_CONFIG_HOME="$probe/config" XDG_DATA_HOME="$probe/data" \
    XDG_STATE_HOME="$probe/state" XDG_CACHE_HOME="$probe/cache" \
    XDG_RUNTIME_DIR="$probe/runtime" GOG_HOME="$probe/gog" \
    GNUPGHOME="$probe/gnupg" PASSWORD_STORE_DIR="$probe/pass" \
    GOG_KEYRING_PASSWORD=synthetic-probe-password \
    PROBE_LOG="$probe/launches.log" "$@"
}
run_gog GOG_KEYRING_BACKEND=file "$GOG_BIN" --version
wc -l < "$probe/launches.log"
# Observed: 2 launcher attempts, despite --version and file backend.

# Requires pass installed, but no initialized password store:
printf 'synthetic-not-a-real-token\n' | run_gog \
  DBUS_SESSION_BUS_ADDRESS=disabled: GOG_KEYRING_BACKEND=auto \
  "$GOG_BIN" --no-input auth import --email [email protected] \
  --refresh-token-stdin
# Fails: pass init your-gpg-id; store token: set token: exit status 1

printf 'synthetic-not-a-real-token\n' | run_gog \
  DBUS_SESSION_BUS_ADDRESS=disabled: GOG_KEYRING_BACKEND=file \
  "$GOG_BIN" --no-input auth import --email [email protected] \
  --refresh-token-stdin
# Succeeds; neither disabled: invocation adds launcher attempts.

The failing fake launcher causes two attempts; it demonstrates startup execution, not daemon persistence. Without pass installed, the second symptom may differ. The first step assumes /run/user/<uid>/bus and dbus-session are absent; godbus checks those before launching.

Cause

Upstream dependency report: 99designs/keyring#103.

Suggestion

Would you be open to (1) avoiding D-Bus until a command actually needs a keyring backend, and (2) treating disabled:/unreachable buses like a missing bus for the auto fallback? Happy to send a PR once we agree on the approach.

Investigated and reproduced with AI assistance (the Astrarch agent team); the reproduction was verified on a real host.

Dominant language
Go
Stars
8.5k
Forks
721
Avg merge
20h
Merged PRs (30d)
59

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/gogcli

All issues in openclaw/gogcli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.