Creating a bug report/issue → no bug report - just ordinary troubleshooting
Required Information
-
DietPi version | G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=12
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
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
- Starting the operating system
- 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. .