DBus-Daemon and gvfs high CPU load - again

Creating a bug report/issue → no bug report - just ordinary troubleshooting

Required Information

  • DietPi version | G_DIETPI_VERSION_CORE=8
    G_LIVE_PATCH_STATUS[0]=‘applied’- Distro version | bullseye

  • Kernel version | Linux 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux

  • SBC model | Intel NUC9i9QNX

  • Power supply used | The one internal (built in)

  • SD card used | 500 GB Samsung 980 PCie 3.0 M.2 NVME SSD (“non-pro”)

Additional Information (if applicable)

  • Software title | dbus-daemon
  • Was the software title installed freshly or updated/migrated? not that i am aware of it
  • Can this issue be replicated on a fresh installation of DietPi?
    No - thats why i rather call it troubleshooting, instead of a bug. Id like to get it solved anyway. Reinstalling my server would most likely take days which i dont have.
  • Bug report ID | 384cade3-68e3-4afb-af21-dab4ab220121

Steps to reproduce

  1. Starting the operating system
  2. Using e.g. htop to monitor CPU usage.
    Example Output:

  0[|||||||||                                        14.6%] Mem[|||||||||||||||||||||||||||||||||||||||||||2.16G/31.1G]
  1[|||                                               4.0%] Swp[                                                 0K/0K]
  2[|||||                                             8.0%] Tasks: 100; 2 running
  3[||||||||                                         13.1%] Load average: 1.53 1.44 1.41
  4[||||                                              5.2%] Uptime: 22:52:57
  5[||||||                                            9.3%]
  6[||||||                                            7.9%]
  7[||||||                                           10.4%]
  8[||||                                              4.0%]
  9[||||||||||||                                     20.1%]
 10[||||||||                                         13.7%]
 11[|||||                                             7.2%]
 12[||||                                              4.0%]
 13[||                                                2.7%]
 14[||||||                                            7.8%]
 15[|||||                                             5.9%]
Avg[||||||                                            8.6%]
    PID USER        RES  NI CPU%▽  TIME+  Command
      1 root      10876   0  0.0  0:05.78 /sbin/init
   1498 hts        218M   0  9.9 59:47.80 ├─ /usr/bin/tvheadend -f -p /run/tvheadend.pid -u hts -g video
   1680 root       3824   0  8.6  2h08:27 ├─ /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --sess   1844 root      15076   0  2.0 31:35.79 ├─ /usr/libexec/gvfs-udisks2-volume-monitor
   1913 root       6912   0  2.0 23:03.17 ├─ /usr/libexec/gvfs-goa-volume-monitor
   1923 root       7224   0  2.0 22:37.50 ├─ /usr/libexec/gvfs-gphoto2-volume-monitor
   1420 adguardho 56352   0  1.3  0:34.47 ├─ /mnt/dietpi_userdata/adguardhome/AdGuardHome
   1755 root       7200   0  1.3 19:55.40 ├─ /usr/libexec/gvfsd
   1815 root       6572   0  1.3 17:02.64 ├─ /usr/libexec/at-spi2-registryd --use-gnome-session
   1918 root       6436   0  1.3 22:27.97 ├─ /usr/libexec/gvfs-mtp-volume-monitor
   1928 root       9752   0  1.3 22:35.72 ├─ /usr/libexec/gvfs-afc-volume-monitor
   1937 root      26832   0  0.7  1:46.94 ├─ /usr/lib/mate-panel/notification-area-applet
   2635 mysql      224M   0  0.7  2:05.40 ├─ /usr/sbin/mariadbd
   3360 plex       189M   0  0.7 46:26.72 ├─ /usr/lib/plexmediaserver/Plex Media Server
   3715 plex      41996  15  0.0  0:19.77 │  ├─ Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plu   3941 plex      11200   0  0.0  0:32.62 │  └─ /usr/lib/plexmediaserver/Plex Tuner Service /usr/lib/plexmediaserver/Res    371 root      16968   0  0.0  0:00.64 ├─ /lib/systemd/systemd-journald
    440 root       5280   0  0.0  0:00.21 ├─ /lib/systemd/systemd-udevd
    644 root       7508   0  0.0  0:01.00 ├─ /usr/sbin/haveged --Foreground --verbose=1
F1Help  F2Setup F3SearchF4FilterF5List  F6SortByF7Nice -F8Nice +F9Kill  F10Quit

Expected behaviour

way less CPU load

Actual behaviour

see htop example above

Extra details

i am using Linux based OS’s since >10 years. I am not exactly a newbie, but most of the time i have been more the power user, instead of the admin. However - i do remember having a similar problem YEARS ago. I believe it was in Debian. And i think i also recall this being called a bug back in time. But i also remember that it had been resolved by 2012…ish… (probably a year earlier). I googled this a lot but did not find anything helpful. Roughly two weeks ago i installed MATE (24) and changed the autostart options to “2” (Desktop with autologin). The basic idea was to have a desktop which i can access remotely when i need to change a settings on a (local) admin webinterface (router, iot devices, other services such as e.g. adguard). And since my server is basically “always on” i considered this a good idea. Coming to think of it i believe it was by that time when the issues started.

A second issue which appeared roughly at the same time - even though i am not sure if its related - is some strange behaviour by tvheadend. Which i documented here: TVHeadend losing access to recordings after reboot - Tvheadend
Basically: tvheadend seems to forget about the recordings it did everytime i reboot the server - even though the recordings are still physically there.

Regarding the dbus-daemon issue it is worth noting that restarting the daemon changes nothing. Killing the daemon and starting it again however seems to mitigate the issue.

I also noted that - for some reason, the default mounts for new SD-Cards or USB drives did change (probably due to an update). Previously it had been /mnt/. Now it is /media//. I realised this at the same time at which i realised the problem with dbus-daemon/gvfs.

If everything else fails i can still revert to a backup from November. .

But this is nothing DietPi tools can do, because DietPi default is /mnt. A switch from /mnt/ to /media is out of the possibility for DietPi script and might be triggered by a 3rd party app you have installed.

why not using something like VNC or XRDP? This would save resource as you don’t need to keep a full desptop running all the time.

Thank you Joulinar.

Thats interesting… Basically the only 3rd party app i installed was TVheadend. And thats been half a year ago.

Do you probably have a “best guess” for me where to start looking?

Regarding the MATE Installation: Very true. I only did this because because the only other computer i have is a huge ESXi Server which has a power draw of ~500 Watts in idle (32 disks, epyc 7742). And since my monitors do have enough inputs and a nice KVM feature built in - i though switching to my server sometimes could help me save some power…

personally I’m not aware on a software that is able to adjust mount points by it’s own

Theoretically no need to keep a full desktop running whole time. Locally you could start a desktop using startx if needed. And from remote, simply use VNC or XRDP. Both will start a desktop on demand.

Cant argue with that. I did now exactly as you proposed (autostart option “0”).
Et voila: gvfs and dbus-daemon utilization returned to almost zero again. The drive are now auto mounted again at /mnt, and my tvheadend was able to find its recordings again…

To be honest: i dont understand why this happened at all, but i am glad it did solve the problems i had.

hmm how does it behave if your start the desktop using startx from command line? Does it mix the mounts? Or issues using dbus?

Sorry for taking a while to respond. Yes - it does indeed both as soon as i use “startx” to start the desktop from the command line. It also stops as soon as i stop X again.

that would mean some software that start together with the desktop mode. Any special software you installed? At least I’m not aware that our default desktop is doing something like this.

Hi, speaking of which i remembered that i did indeed install teamviewer to be able to manage the desktop from remote. However i did not really use it. I just uninstalled it (removed it using dpkg -r). I will retry starting X later today.

Update: the same as before. The same high cpu load again. I am just connected remotely so i cannot test what happens when i plug in a usb drive (if its being indeed connected again to /media).

Update 2:

Yes - it does indeed again mount new drives to /media.