-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Comments
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. |
Thanks @vegaman for reporting this and providing a workaround. We ran into this issue too with |
Running into this issue on vault version To be clear, is the workaround just Also in my environment, |
@jkhuang-42, please see this KB article on how to solve this in the meantime. The article also covers the situation with no |
I run into this on 2 of the 3 servers that run vault It's easy to reproduce:
and to work around (as mentioned in the opening comment):
Without doing anything, Vault runs ok (by the looks of it) on all three servers. I have a few questions:
Thanks for the clarification. |
I am running into the same issue as @aswen when upgrading to v1.17.0. |
We've just upgraded and have the same on
|
Just installed vault on RHEL8
|
hi folks, this warning is coming from related issues:
if you found false positives (where the warning is emitted, but there are no actual orphaned |
When will the |
Edit: Nevermind I see it when using "sudo vault" cli. sudo vault --help
sudo yum -y install vault
|
Hey I still get same error even after upgrade to v1.17.3...
Work around works:
But still want to know how to fix this issue. Thank you. |
The dependency was updated yesterday and will probably make it to the next release. |
What version number will include this fix? |
Hello, the same error persists with version 1.17.6 $ 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.6 (69a720d5d940bfcd590d7c24f3c98f178673d796), built 2024-09-24T19:48:40Z And for me, the workaround does not work. $ sudo vault write ssh-client-signer/sign/my-role public_key=@$HOME/.ssh/id_rsa_client.pub
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.
WARNING! VAULT_ADDR and -address unset. Defaulting to https://127.0.0.1:8200.
Error writing data to ssh-client-signer/sign/my-role: Put "https://127.0.0.1:8200/v1/ssh-client-signer/sign/my-role": dial tcp 127.0.0.1:8200: connect: connection refused |
Confirming it is not fixed in 1.17.6 $ ./vault version $ export DBUS_SESSION_BUS_ADDRESS=/dev/null $ ./vault version |
the offending piece of code was only reverted in gosnowflake release v1.11.0, so until the gosnowflake dependency is below v1.11.0, this indeed will still appear i'm afraid i see gosnowflake bumped to v1.11.0 (the 'fixed' version) with vault v1.18.0-rc1 so i guess you could give that version a shot, or wait until next release |
Can confirm this is now fixed in vault |
1.18.0 resolved the issue for me as well. |
Describe the bug
Running
vault
as a user withoutDBUS_SESSION_BUS_ADDRESS
set and no/run/user/<uid>/bus
file causes vault to rundbus-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:
vault --version
with noDBUS_SESSION_BUS_ADDRESS
set and no/run/user/<uid>/bus
filedbus-daemon
process running as the user that ran vault.Expected behavior
There should be no extra processes left running.
Environment:
vault version
): v1.14.1Additional context
This is related to the godbus/dbus issue raised here godbus/dbus#372
Testing this as a workaround does avoid the issue:
The text was updated successfully, but these errors were encountered: