Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running vault v1.14.1 without DBUS_SESSION_BUS_ADDRESS set and no /run/user/<uid>/bus launches a persistent dbus-daemon #22560

Closed
brinnjoyce opened this issue Aug 25, 2023 · 7 comments
Labels
core/dev core Issues and Pull-Requests specific to Vault Core

Comments

@brinnjoyce
Copy link

brinnjoyce commented Aug 25, 2023

Describe the bug
Running vault as a user without DBUS_SESSION_BUS_ADDRESS set and no /run/user/<uid>/bus file causes vault to run dbus-launch which launches a persistent dbus-daemon process like this:
/usr/bin/dbus-daemon --syslog --fork --print-pid 4 --print-address 6 --session.

A new dbus-daemon will be launched every time vault is run.

The dbus-daemon processes use inotify instances, so if vault is executed enough times (configuration management in our instance) the user running vault will run into the fs.inotify.max_user_instances limit or fd limits causing issues for systemd etc.

To Reproduce
Steps to reproduce the behavior:

  1. Run vault --version with no DBUS_SESSION_BUS_ADDRESS set and no /run/user/<uid>/bus file
  2. See that there is now a new dbus-daemon process running as the user that ran vault.

Expected behavior
There should be no extra processes left running.

Environment:

  • Vault CLI Version (retrieve with vault version): v1.14.1
  • Server Operating System/Architecture: Ubuntu 18.04/22.04 amd64

Additional context

This is related to the godbus/dbus issue raised here godbus/dbus#372
Testing this as a workaround does avoid the issue:

env DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus vault --version
@brinnjoyce brinnjoyce changed the title Running vault v1.14.1 as root launches a forked dbus-daemon Running vault v1.14.1 without DBUS_SESSION_BUS_ADDRESS set and no /run/user/<uid>/bus launches a persistent dbus-daemon Aug 25, 2023
@biazmoreira biazmoreira added core Issues and Pull-Requests specific to Vault Core core/dev labels Aug 29, 2023
@biazmoreira
Copy link
Contributor

This is related to the snowflake bug, which I re-opened here snowflakedb/gosnowflake#901

We'll try to work this around with snowflake before trying to fix it directly in Vault.

@danielhass
Copy link

Thanks @vegaman for reporting this and providing a workaround.

We ran into this issue too with v1.14.1 and setting the env variable DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus seems to be a proper workaround so far.

@jkhuang-42
Copy link

Running into this issue on vault version v1.14.3-ent but the workaround did not seem to have any effect, new dbus daemons still seem to be generated each time vault is called.

To be clear, is the workaround just export DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus ?

Also in my environment, XDG_RUNTIME_DIR does not have a value, is that an issue?

@Soromeister
Copy link
Contributor

@jkhuang-42, please see this KB article on how to solve this in the meantime. The article also covers the situation with no XDG_RUNTIME_DIR value.

@aswen
Copy link

aswen commented Jun 13, 2024

I run into this on 2 of the 3 servers that run vault 1.17.0-1 (Debian Bookworm).

It's easy to reproduce:

$ vault --version
WARN[0000]log.go:244 gosnowflake.(*defaultLogger).Warn DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processes. To avoid this, set envvar DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus (if it exists) or DBUS_SESSION_BUS_ADDRESS=/dev/null. 
Vault v1.17.0 (72850df1bc10581b74ba5f0f7b3736f31c034235), built 2024-06-10T10:11:34Z

and to work around (as mentioned in the opening comment):

$ env DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus vault --version
Vault v1.17.0 (72850df1bc10581b74ba5f0f7b3736f31c034235), built 2024-06-10T10:11:34Z

Without doing anything, Vault runs ok (by the looks of it) on all three servers.

I have a few questions:

  1. What is the risk of running Vault without fixing this? I see no issues on the two vault servers that warn.
  2. Is there anything we should do to fix this permanently?
  3. I see this issue was closed 9 months ago. Did we miss something that fixes this? Should we change something on our servers?
  4. I don't understand that on one of our servers this problem is not manifesting. Even though we don't have DBUS_SESSION_BUS_ADDRESS set on that one.

Thanks for the clarification.

@PJ1288
Copy link

PJ1288 commented Jun 13, 2024

I am running into the same issue as @aswen when upgrading to v1.17.0.
level=warning msg="DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processe>

@yaboeing
Copy link

We've just upgraded and have the same on

vault --version
WARN[0000]log.go:244 gosnowflake.(*defaultLogger).Warn DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processes. To avoid this, set envvar DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus (if it exists) or DBUS_SESSION_BUS_ADDRESS=/dev/null.
Vault v1.17.0 (72850df1bc10581b74ba5f0f7b3736f31c034235), built 2024-06-10T10:11:34Z

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core/dev core Issues and Pull-Requests specific to Vault Core
Projects
None yet
Development

No branches or pull requests

8 participants