[BUG] NVIDIA v495.29.05 driver spamming dbus-enabled applications with invalid messages

@dzy201415 @ionen @Tatsh FYI: Gentoo incorporated the binary patch with =x11-drivers/nvidia-drivers-495.44-r2 (latest ~amd64)

nvidia-fake-powerd does the job, thank you all…but I assume the spamming of the dbus is still going on in the background which I am not very happy about it. What a strange/silly bug and even stranger to still be present after so many revisions of the driver.
(Running Endeavour OS with 495.44 drivers on a 5950x)

Driver version 495.46 seems to have fixed this issue for me. Can anyone confirm?

A reliable way to check is with dbus-monitor --system (as root), will see something like potentially ~10000 dbus powerd request per second when using OpenGL if the issue still exists.

And unfortunately, this still happens with 495.46. As far as I can tell, 495.46 is just adding support for additional cards and didn’t really change anything (its Changelog is mentioning the changes from previous versions – I’d imagine a bigger release is coming up).

Unless using wayland/GBM, for now I personally recommend to just use 470 production branch (470.93 was newly released and still isn’t affected) rather than elaborate workarounds if used distro allows it. But fake-powerd or the binary patch (applies as-is for .46 too) still works (latter still to be done with caution).


You are right, I was running dbus-monitor --system without root and didn’t had that spam. With root I can see it as well. Bummer.

It is time for NVIDIA officials to speak up, don’t you think ?.. I cannot understand that such a huge flaw is left unfixed for three consecutive releases (and two releases and over one month and a half after I reported this bug).


I can confirm 495.46 spams /var/log/messages with the dbus-daemon messages and causes the kwin_x11 process to be pegged at 100% CPU, whereas 470.74 solves the problem (no messages and kwin_x11 behaves fine).

I’m on Slackware64-current (so no systemd here).

I did not try the “nvidia-fake-powerd” solution, as it’s easy enough to just revert to the 470 series driver.

Hi, I’m trying your solution, but I’m getting this error on Ubuntu 20.04LTS:

systemctl status nvidia-fake-powerd.service
● nvidia-fake-powerd.service - NVIDIA fake powerd service
     Loaded: loaded (/etc/systemd/system/nvidia-fake-powerd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2021-12-16 10:11:50 CET; 10s ago
    Process: 375891 ExecStart=/usr/bin/dbus-test-tool black-hole --system --name=nvidia.powerd.server (code=exited, status=217/USER)
   Main PID: 375891 (code=exited, status=217/USER)

pro 16 10:11:50 PC-3090 systemd[1]: Starting NVIDIA fake powerd service...
pro 16 10:11:50 PC-3090 systemd[375891]: nvidia-fake-powerd.service: Failed to determine user credentials: No such process
pro 16 10:11:50 PC-3090 systemd[375891]: nvidia-fake-powerd.service: Failed at step USER spawning /usr/bin/dbus-test-tool: No such process
pro 16 10:11:50 PC-3090 systemd[1]: nvidia-fake-powerd.service: Main process exited, code=exited, status=217/USER
pro 16 10:11:50 PC-3090 systemd[1]: nvidia-fake-powerd.service: Failed with result 'exit-code'.
pro 16 10:11:50 PC-3090 systemd[1]: Failed to start NVIDIA fake powerd service.

Would you know what’s going on? Thanks

There are a couple of issues with Ubuntu that will require some tweaks to the deployment. First, the dbus-test-tool isn’t installed by default. For that you’ll need to apt install dbus-tests. Next, the system account for dbus is named messagebus. You’ll need to rename the user in both files. The following changes allow it to start within my 20.04 LTS test VM:


<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
        <policy user="messagebus">
                <allow own="nvidia.powerd.server"/>
        <policy context="default">
                <allow send_destination="nvidia.powerd.server"/>
                <allow receive_sender="nvidia.powerd.server"/>


Description=NVIDIA fake powerd service

ExecStart=/usr/bin/dbus-test-tool black-hole --system --name=nvidia.powerd.server


And of course:

systemctl daemon-reload
systemctl restart nvidia-fake-powerd.service
systemctl status nvidia-fake-powerd.service

Great, thanks… the user was the problem, I didn’t know the name :)

But weird thing is that even after I did config with wrong username, after reboot, the messages didn’t appear anymore. Even though the service nvidia-fake-powerd failed to start.

The nvidia-fake-powerd didn’t solved the issue for me.

I’m on Garuda.

@user97930 That makes sense because it takes time for the dbus message queue to fill up if there is no valid destination to route these messages.

@qumaciel Did you follow the instructions to enable and start the service on boot? Did you also reboot to clear the dbus queue? If the service starts correctly without any errors (systemctl status nvidia-fake-powerd.service), then run dbus-monitor --system as the root user and inspect for errors or post a sample of the output here.

This also fixes an issue with a laggy external display/100% CPU under Xorg when the internal panel is disabled on an NVIDIA-based laptop.

Thanks for the AUR package, it fixed it for me.
In my case it was mostly Google Chrome and KDE spamming the journal with these messages. They didn’t explicitly mention nvidia-powerd as the destination - just “1:29” or similar, but they stopped as soon as I started the nvidia-fake-powerd service.

This also worked for 495.46.

Just a note for other to remember to use one or the other. If you use the AUR, do not manually do this file creation.
I used this method, provided by user16974, and it worked perfectly. Thank you.

1 Like

for nixos, this seems to work to prevent journal spamming atleast: workaround for nvidia dbus errors for nix https://forums.developer.nvidia.com/t/bug-nvidia-v495-29-05-driver-spamming-dbus-enabled-applications-with-invalid-messages/192892/36 · GitHub

1 Like

How is this reported in October of last year but not even acknowledged? Just noticed dbus-daemon keeps taking up 2.4GB and it’s all Nvidia messages.

Report about this on Arch Linux tracker - FS#72903 : [nvidia] dbus spamming

This bug is fixed in the next series, the 510.xx beta changelog mentions it:

  • Fixed a bug which caused OpenGL and Vulkan applications to generate excessive traffic over dbus while attempting to communicate with nvidia-powerd, even though nvidia-powerd was not running.



For me it is not. I disabled the fake service, installed the driver, rebooted and 20 hours later the dbus queue was full and the dbus process consuming over 300mb. Re-enabled the fake service and the full queue spam stopped immediately.