[SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

greenjeans · 2025-09-17 20:07:27

So both the folders mentioned in the title contain a dbus file for the session you're in, and generate a new one every time you re-boot, but it's not deleting the old ones, just checked my main partition which was installed in Nov. 2023 and it has over 750 files in that session-bus folder.

Root creates a new one too any time you log-in as root, and those build up as well.

Seems like something ought to clear the old one(s) out when you shutdown.

@fsmithred ; in the Refracta-Snapshot excludes file, /home/(user)/.dbus is excluded, and so when you boot/install the live iso it just has the new one created when you boot up. But root's version is not excluded by default, lol just found a lot of files in a new version of Vuu-do i'm making in root's .dbus directory, about 150 of 'em.

Could the /root/.dbus directory be safely excluded as well?

Bleachbit isn't set to clean the .dbus/session-bus folder because you can't remove all of them, you need the most recent one. But am wondering if something could/should be added to a shutdown script to remove the old files.

golinux · 2025-09-17 20:26:11

Disk space is not an issue for me but I still I checked my stats for /.dbus/session-bus/:

125 items, totaling 56.2 KiB (57,552 bytes)

@fsmithred: Should I do some housecleaning?

fsmithred · 2025-09-17 21:13:59

Nice find. I'll add it to the excludes file. You should probably keep the newest one, but the rest can be deleted.

I've got over 200 of them and I hardly ever reboot. The file name is your dbus machine-id which changes on every reboot in devuan unless you edit /etc/default/dbus or run a script that changes it for you. (I have one)

OK, I just ran my script and changed /var/lib/dbus/machine-id. The file in ~/.dbus/session-bus did not change, but when I switched to root in a terminal, the new id was in /root/.dbus/session-bus. I guess if I log out and in, then user will get the new number.

Maybe this needs another line or two. (Note: Most of this code was borrowed from a live-config script.)
EDIT: Note 2: no guarantee that it won't screw something up that needs a consistent machine-id. Also no guarantee that it will prevent your machine from being identified.

#!/bin/sh
# update-machineid
# Change /var/lib/dbus/machine-id manually.

MACHINEID=/var/lib/dbus/machine-id
UUIDGEN=/usr/bin/dbus-uuidgen
UUIDGEN_OPTS=--ensure

if [ "$(id -u)" -ne 0 ] ; then
        echo " You need to be root."
        exit 1
fi

if [ -f "${MACHINEID}" ] && [ -x "$UUIDGEN" ] ; then
	OLD_ID=$(cat $MACHINEID)
	rm -f "${MACHINEID}"
    $UUIDGEN $UUIDGEN_OPTS
	NEW_ID=$(cat $MACHINEID)
	notify-send -t 5000 "Changed dbus machine-id
 old: $OLD_ID
new: $NEW_ID" 
fi

exit 0

Altoid · 2025-09-17 21:27:48

Hello:

greenjeans wrote:

Seems like something ought to clear the old one(s) out ...

Passed by, saw your post and decided to see what was up in my Daedalus installation:

~$ ls -h -l ~/.dbus/session-bus
total 12K
-rw-r--r-- 1 groucho groucho 462 Sep 17 17:32 26a708d3d7dc6778fc6ff9f55921b024-0
-rw-r--r-- 1 groucho groucho 462 Jun 10  2024 26a708d3d7dc6778fc6ff9f55921b024-1
-rw-r--r-- 1 groucho groucho 465 Mar 14  2019 26a708d3d7dc6778fc6ff9f55921b024-2
~$

Newest entry is from today, the time is (most probably) when I booted/logged in.
But there are two more: one from last year and yet another one but from 2019. (!)

# ls -h -l ~/.dbus/session-bus
total 8.0K
-rw-r--r-- 1 root root 463 Sep 11 21:47 26a708d3d7dc6778fc6ff9f55921b024-0
-rw-r--r-- 1 root root 469 Oct 17  2018 26a708d3d7dc6778fc6ff9f55921b024-1
#

I don't do too much root but I must have done something last 11/09.
And last 17/10/2018 also. (!) <--- soon to be 7 years old, when Jesse was running this box.

I concurr, there may be some housekeeping to do.

@greenjeans: good catch ...
Q: these files are supposed to be temporary ie: belonging to the current session, right?

Edit:
I never leave my box on, just in case.
I boot the system early while I make my espresso and do not leave it on if I am not home or not doing something on it. eg: clonezilla backups
So it gets rebooted at least a half dozen times a day, sometimes more.

Probably the reason why my file count was so low compared to you, @golinux and @fsmithred.
But still, why did I have (nuked them) files from 2024, 2019 and 2018?

Best,

A.

Last edited by Altoid (2025-09-17 21:40:15)

greenjeans · 2025-09-17 21:45:13

So it gets rebooted at least a half dozen times a day, sometimes more.

You should have a ton of files then, for some reason yours is kicking out the old ones.

To clarify i'm running Daedalus too. weird.

fsmithred · 2025-09-17 21:56:44

I should have mentioned this in my last post. Default behavior in devuan is for /var/lib/dbus/machine-id to be replaced on reboot. This can be disabled to revert to the upstream default by commenting the line that says: IDTYPE="RANDOM" in /etc/default/dbus. If you do that, the id number will be constant. I don't know if there are other situations where it will change. Maybe on update of dbus packages? That's just a guess.

Altoid · 2025-09-17 22:36:55

Hello:

greenjeans wrote:

... should have a ton of files then ...

Why?

Not if it is (as you have mentioned) working properly.
ie: renewing the files on every boot.

Still, I did have those two very old files.

I rebooted after nuking the vintage files and the system replaced the previous valid one with a new one.
ie: just one file with the proper boot time/date present.

greenjeans wrote:

... for some reason yours is kicking out the old ones.

Lately I have mentioned that my present system ie: Daedalus started off as Jesse and from the date of the oldest file I found in the root didrectory, that would have been back in 2017.

Makes sense, my first post here is from that year.

The fact that this box has seen a succession of dist-upgrades, with all but one (a Beowulf to Chimaera nightmare) being reasonably smooth may have to be taken into account to evaluate this find.

Could it be that there was a change (or introduced bug) in how dbus managed those files and my system (at some point) retained a previous configuration? No idea, just a guess.

Let me know if you need more data.

Best,

A.

RedGreen925 · 2025-09-17 22:57:13

Strange mine seems to work just fine without any of it in the root directory, the user directory seems to just have directories with nothing in them..

zeus@9600k:~$ du -h .dbus/
12K	.dbus/session-bus
16K	.dbus/

root@9600k:~# du -h .dbus/
du: cannot access '.dbus/': No such file or directory

root@9600k:~# cat /etc/os-release
PRETTY_NAME="Devuan GNU/Linux 6 (excalibur)"
NAME="Devuan GNU/Linux"
VERSION_ID="6"
VERSION="6 (excalibur)"
VERSION_CODENAME="excalibur"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

Edit: I would add I did nothing special to disable any of it.

Last edited by RedGreen925 (2025-09-17 22:59:07)

EDX-0 · 2025-09-18 03:41:04

redgreen925 do ya use a desktop environment like mate, xfce, kde, etc... or have a setup with a plain window manager and tools composed on top of it?

it could be that for all of use whom get the files piled up is because we are using plain window managers that do not purge their active dbus session address file upon session end (logoff, shutdown, reboot)

Altoid · 2025-09-18 03:47:36

Hello:

I forgot to add this bit:

fsmithred wrote:

Default behavior in devuan is for /var/lib/dbus/machine-id to be replaced on reboot.
... disabled to revert to the upstream default by commenting the line that says: IDTYPE="RANDOM" in /etc/default/dbus.
If you do that, the id number will be constant.

My /etc/default/dbus says this:

$ cat /etc/default/dbus
# This is a configuration file for /etc/init.d/dbus; it allows you to
# perform common modifications to the behavior of the dbus daemon
# startup without editing the init script (and thus getting prompted
# by dpkg on upgrades).  We all love dpkg prompts.

# Parameters to pass to dbus.
PARAMS=""

# IDTYPE: how to deal with /var/lib/dbus/machine-id:
#
# if IDTYPE="RANDOM": regenerate /var/lib/dbus/machine-id at each boot
# else keep it fixed across reboots
IDTYPE="RANDOM"   ### not commented
$

Machine-id is set thus:

$ cat /var/lib/dbus/machine-id
26a708d3d7dc6778fc6ff9f55921b024
$

So ...
Unless I got it wrong, on reboot the machine-id should change in a random manner.
Right?

Now, here's the thing ®: it does not and apparently has not changed in the last eight years or so.

In my first post in this thread you can see that all the files I found have the same machine-id:

~$ ls -h -l ~/.dbus/session-bus
total 12K
-rw-r--r-- 1 groucho groucho 462 Sep 17 17:32 26a708d3d7dc6778fc6ff9f55921b024-0
-rw-r--r-- 1 groucho groucho 462 Jun 10  2024 26a708d3d7dc6778fc6ff9f55921b024-1
-rw-r--r-- 1 groucho groucho 465 Mar 14  2019 26a708d3d7dc6778fc6ff9f55921b024-2
~$

# ls -h -l ~/.dbus/session-bus
total 8.0K
-rw-r--r-- 1 root root 463 Sep 11 21:47 26a708d3d7dc6778fc6ff9f55921b024-0
-rw-r--r-- 1 root root 469 Oct 17  2018 26a708d3d7dc6778fc6ff9f55921b024-1
#

After rebooting (twice), the same random number is there:

$ cat /var/lib/dbus/machine-id
26a708d3d7dc6778fc6ff9f55921b024
$

And it matches what I find both in both ~/.dbus/session-bus directories:

$ ls -h -l ~/.dbus/session-bus
total 4.0K
-rw-r--r-- 1 groucho groucho 462 Sep 18 00:23 26a708d3d7dc6778fc6ff9f55921b024-0
$

# ls -h -l ~/.dbus/session-bus
total 4.0K
-rw-r--r-- 1 root root 463 Sep 11 21:47 26a708d3d7dc6778fc6ff9f55921b024-0
#

Q: I don't care one way or the other if my machine-id changes or not, but am I missing something here?

Best,

A.

Last edited by Altoid (2025-09-18 11:01:36)

RedGreen925 · 2025-09-18 03:54:03

redgreen925 do ya use a desktop environment like mate, xfce, kde

I have used KDE for the last twenty-six or so years on Linux since the pre 1.0 days when I installed it during my rpm hell days on Redhat 5.2 way back then before I found the Mandrake that had it per-installed a year or two later. Then I moved onto Debian Woody when it came out and found the one true OS before they bastardized it with the systemd garbage. My dbus config.

eus@9600k:~$ cat /etc/default/dbus
# This is a configuration file for /etc/init.d/dbus; it allows you to
# perform common modifications to the behavior of the dbus daemon
# startup without editing the init script (and thus getting prompted
# by dpkg on upgrades).  We all love dpkg prompts.

# Parameters to pass to dbus.
PARAMS=""

# IDTYPE: how to deal with /var/lib/dbus/machine-id:
# 
# if IDTYPE="RANDOM": regenerate /var/lib/dbus/machine-id at each boot
# else keep it fixed across reboots
IDTYPE="RANDOM"

EDX-0 · 2025-09-18 05:08:43

thanks, i will check later on the source code of the kde session process to see if there's something that specifically deals with the $HOME/.dbus/session-bus/ files

User479 · 2025-09-18 12:14:31

I also have IDTYPE="RANDOM" yet the machine-id has been unchanged since at least 2017. One thing that hasn't been mentioned here is interactions with /etc/machine-id. Debian's man page for machine-id talks a lot about systemd so it would seem to be mostly irrelevant for devuan.

https://manpages.debian.org/trixie/syst … .5.en.html

g4sra · 2025-09-18 13:50:11

root@localhost:~# ls -l /var/lib/dbus/machine-id
-rw-r--r-- 1 root root 33 Sep 18 09:09 /var/lib/dbus/machine-id

greenjeans · 2025-09-18 16:02:58

it could be that for all of use whom get the files piled up is because we are using plain window managers that do not purge their active dbus session address file upon session end (logoff, shutdown, reboot)

Happening here in Mate as well as Openbox.

Altoid · 2025-09-18 16:16:40

Hello:

User479 wrote:

... so it would seem to be mostly irrelevant for devuan.

Maybe, not necessarily.
At least not yet. 8^°

Which begs the following question:
In whose interests or (better yet, to what end) does my box/system need to have a unique machine-id.
ie: my machine-id seems to have been set long ago and it has not changed (much like your own situation) since 17/10/2018.

Best,

A.

greenjeans · 2025-09-18 16:51:01

Which begs the following question:
In whose interests or (better yet, to what end) does my box/system need to have a unique machine-id.

https://ianlecorbeau.com/blog/resetting … -boot.html

"The /etc/machine-id and /var/lib/dbus/machine-id files can potentially be used to fingerprint a system over the long term. Of course, some will argue that this is merely FUD, but it really isn't. The key word here is *potentially*.
There may not be any indications that this file is actively being used in a malicious capacity by anyone (or anything), but the fact that it can be used in such a manner should be enough for someone who cares about their privacy to take steps to at least minimize this potential threat."

Also from that article -

Distributions like Devuan, tails and whonix already take care of regenerating machine-id every boot, so this script is not necessary if you're using one of them.

Altoid · 2025-09-18 18:58:45

Hello:

iantecorbeau.com wrote:

The /etc/machine-id and /var/lib/dbus/machine-id files can potentially be used to fingerprint a system ...

I thought as much, asked to verify.

iantecorbeau.com wrote:

... Devuan, tails and whonix already take care of regenerating machine-id every boot ...

Yes?
I don't see that happening.
ie: /etc/default/dbus is set to IDTYPE="RANDOM" (see my previous post)
And it seems that I am not the only one.

Any idea why?
Is there a bug/problem to be addressed somewhere in my system Devuan?
If so, it has been there since (at least) Jesse ASCII*.

*The dbus patch to generate new dbus machine-id on boot was added in ASCII.

Best,

A.

Last edited by Altoid (2025-09-18 19:15:29)

greenjeans · 2025-09-18 19:04:16

^^Yeah the inconsistency is befuddling, need to find the common denominator.

In general I think swapping machine id's every boot is a good thing, but need to find out why old ones aren't getting deleted, and why for some folks it's just not happening.

Altoid · 2025-09-18 19:56:49

Hello:

greenjeans wrote:

... swapping machine id's every boot is a good thing ...

I agree.
Though there are a great many other fingerprinting / tracking devices at work.
But one-by-one is the way.

greenjeans wrote:

...find out why old ones aren't getting deleted, and why for some folks it's just not happening.

I have not seen anyone (yet) report that their system is actually working as intended. ie: creating a new machine-id at boot.

In my case, given the files' datestamps, it never worked.
Or maybe it worked sometimes and not others. eg: with the Jesse to ASCII dist-upgrade

Best,

A.

rolfie · 2025-09-18 20:02:53

Same on my Daedalus: 340 files since installation.

New installation, the files do not take very much space. New machine ID on every boot.

Last edited by rolfie (2025-09-18 20:39:36)

greenjeans · 2025-09-18 20:37:00

I have not seen anyone (yet) report that their system is actually working as intended. ie: creating a new machine-id at boot.

Well sure you have, that's the main problem I reported on, myself and others are getting a fresh unique one every boot, it's just not deleting the old ones when it creates new ones, thus the buildup of files.

And then there's secondary issues now, like yours where it's not creating new ones to start with.

But since I know you, I have to ask, is this one of your frankenmachines we're talking about and how much hacking have you done on it? LOL! Not judging brother, i'm a system chopper myself from way back, but for troubleshooting this thing we need some examples that are a little more mainstream I think.

Altoid · 2025-09-18 20:41:20

Hello:

Rolfie wrote:

Same on my Daedalus: 340 files ...

Just checked my 1000HE netbook running Beowulf with a backported kernel.
Was never upgraded because I fear for my coffee roasting software.

Did not bother to count how many after I saw that the third MC screen passed by.
Must have been 600+ files which I promptly nuked, but it is just a guess.

Curiously enough, I never came across any line in dmesg (or other logs I look at) saying something about this in any one of my boxes, ever.
eg:

[000.0000] generating random machine-id

or

[000.0000] generating random machine-id failed - old machine-id used

Methinks that the patch applied to ASCII never really worked and if it did, it did so for just a short while or only in ASCII.
Not being something that would make a light blink (so to speak) it just laid there, dormant.
And nobody ever checked.

Till @greenjeans. 8^)

Best,

A.

Last edited by Altoid (2025-09-18 21:06:07)

greenjeans · 2025-09-18 20:47:23

@Altoid on the box with the machine-id that never changes, do you have an /etc/machine-id file?

Altoid · 2025-09-18 21:01:38

Hello:

greenjeans wrote:

... one of your frankenmachines we're talking about ...

Indeed ...
My best one. 8^D

But my franken-ventions are hardware only.
ie: I am just a mechanic of sorts. I took apart my tricycle at age 4, my father could not believe it.

I leave the software stuff to the people who are more intelligent than I.
That said, I don't think it matters which hardware the system runs on.

If the system is Devuan based and dbus is present, the [multiple files] problem is there.
My headless Chimaera VM has a machine-id but no /var/lib/dbus/ machine-id files, so maybe it is a dbus bug.

But the real problem is not really the latter, it is the existence of a machine-id.
That was apparently solved with a patch when ASCII was released. (as per the release notes)

But now the problem is that either the ASCII patch never worked / does not work now / was never applied in post-ASCII releases.

Are the Devuan devs aware of this?

Edit:

greenjeans wrote:

... do you have an /etc/machine-id file?

Of course, I say so in one of my last posts.

I wrote:

Machine-id is set thus:

$ cat /var/lib/dbus/machine-id
26a708d3d7dc6778fc6ff9f55921b024
$

Best,

A.

Last edited by Altoid (2025-09-18 21:05:08)

The officially official Devuan Forum!

#1 2025-09-17 20:07:27

[SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#2 2025-09-17 20:26:11

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#3 2025-09-17 21:13:59

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#4 2025-09-17 21:27:48

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#5 2025-09-17 21:45:13

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#6 2025-09-17 21:56:44

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#7 2025-09-17 22:36:55

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#8 2025-09-17 22:57:13

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#9 2025-09-18 03:41:04

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#10 2025-09-18 03:47:36

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#11 2025-09-18 03:54:03

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#12 2025-09-18 05:08:43

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#13 2025-09-18 12:14:31

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#14 2025-09-18 13:50:11

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#15 2025-09-18 16:02:58

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#16 2025-09-18 16:16:40

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#17 2025-09-18 16:51:01

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#18 2025-09-18 18:58:45

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#19 2025-09-18 19:04:16

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#20 2025-09-18 19:56:49

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#21 2025-09-18 20:02:53

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#22 2025-09-18 20:37:00

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#23 2025-09-18 20:41:20

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#24 2025-09-18 20:47:23

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

#25 2025-09-18 21:01:38

Re: [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus

Board footer