on my system, the machine-id is defined in /var/lib/dbus/machine-id.

I have the same file in all mine, doesn't stop it from genning new ones in session-bus every boot.

I don't even have that folder on my Daedalus installs, just ~/.dbus/session-bus/

Oops, that's it, I just misspelled it.

That makes sense. I have a vague memory of doing something like that once.

I have that file too, which would explain why I'm not seeing the accumulation of randomly named files.

So looks like whatever display manager is used, a folder is created in /var/lib/(display-manager)/.dbus/session-bus/*

But i'm still trying to figure out what purpose it serves and how they got there, after logging in and out of that partition multiple times yesterday, that folder was not added to by the system, still just 21 files that all show they were created when I started a snapshot last week.

I did finally get around to messing with that, I deleted all the files in that folder, and rebooted multiple times and logins/logouts, and so far nothing has been generated back into that folder. And nothing seems amiss with the system whatsoever.  I'm wondering if the system generates a file in there on install, and never gens another, which is possible even though I had 20+ files in there because this system has been snapshotted/installed many times and I guess it just genned a new one every time?

EDIT: Started a different thread about this and solved it.

Dbus really gets around it seems.

So looks like whatever display manager is used, a folder is created in /var/lib/(display-manager)/.dbus/session-bus/*

But i'm still trying to figure out what purpose it serves and how they got there, after logging in and out of that partition multiple times yesterday, that folder was not added to by the system, still just 21 files that all show they were created when I started a snapshot last week.

The init script is working perfectly it seems, several days of testing now and no issues.

To clean /var/lib/(display-manager)/.dbus/session-bus/* in a similar fashion would take some extra work, have to list all available display managers, there's not that many but still.

And now I just found in /var/lib/NetworkManager some 181 files, 5 of which are config/info files of one sort or another, and all the rest are eth0-lease files, and all of those say they were created at the exact same time I started that snapshot last Wednesday.

So 176 files that all do the same thing, sample filename and it's contents:
internal-f368e190-5bd0-37e6-b42d-75f71b63df1d-eth0.lease

# This is private data. Do not parse.
ADDRESS=192.168.2.5

i noticed the accumulating files last year but was not curious enough
to search for more information. just added rm's to my weekly clean-up
script.

based on another post, i commented-out IDTYPE=RANDOM, which prevents
the file accumulation and reverted the changes to my clean-up script.

based on this thread it appears that IDTYPE=RANDOM is a "good thing"
so those deletes will be getting added back.

my set-up is daedalus+KDE so sddm and pulseaudio are also installed.

on my system, the machine-id is defined in /var/lib/dbus/machine-id.
there is no /etc/machine-id file.

in addition to the ~/.dbus/session-bus and /root/.dbus/session-bus
directories mentioned in post #1, with KDE there is also the
/var/lib/sddm/.dbus/session-bus directory to clean-up.

and pulseaudio pollutes ~/.config/pulse with 6 files/directories, so
need to clean-up these as well:

   <machine-id>-card-database.tdb
   <machine-id>-default-sink
   <machine-id>-default-source
   <machine-id>-device-volumes.tdb
   <machine-id>-runtime
   <machine-id>-stream-volumes.tdb

no idea how this will change with excalibur.

If you switch to console without stopping the desktop, log in and then start a second desktop on :1, you'll get another file in ~/.dbus/session-bus with the same number as /var/lib/dbus/machine-id except with -1 at the end, but only if there's a number in dbus/machine-id. If you delete that file first, you won't get another one in your home unless you also restart dbus. (e.g. cycle through 'init 1' and 'ctrl-d')

> ctrl-alt-f1 to get to console
> log in as user
Run:
  startx -- :1 

Ceres system completely lacks the file at /etc/default/dbus. Nonetheless, dbus is definitely installed and running. I'm also missing /etc/machine-id.

On a new Devuan install there shouldn't be an /etc/machine-id, so that seems correct.

I don't even have that folder on my Daedalus installs, just ~/.dbus/session-bus/, perhaps somebody has renamed it in Ceres.

They may have moved somewhere less conspicuous.
ie: hidden it

Or maybe it has become a part of the systemd OS.

I don't have one in my Daedalus system: I deleted it.
No issues.

That one you can delete.
If what we have seen up to now holds, the system behaviour should be that the -0 file gets overwitten at boot.

Best,

A.

Another puzzle: there are exactly two files in ~/.dbus/session-id/. The files have almost the exact same names, except that one ends in -0, and the other ends in -1. The -0 file gets overwritten on each reboot, but with the exact same name. The -1 file was created back on 8-24, and hasn't been touched since.

This will nuke them all:

find / -type f -wholename "*.dbus/session-bus/*" -exec rm {} \;

I agree.
syslog is a mess to look in but lets thank the IT gods for being able to do so.

Hmm ...
Why not just to dmesg?

Best,

A.

Without knowing anything much about how/why this happens, what I have observed is that, wherever it is that a */.dbus/session-bus/ directory is located*, stale files remained.
ie: stale in the sense that they are session-id files belonging to previous sessions.
* /root, /home/user, /var/lib/lightdm or anywhere but /tmp

This is something that has (evidently) been happening for the longest while and gone unnoticed, never before reported as an anomaly.
A bug? Most probably.
A feature to track previous dbus sessions?
If so, to what practical end?

It is definitely related to installations with some sort of desktop or WM.
eg: my 1000HE runs a dated Devuan (5.10 kernel and Openbox) and when I went to look I found a staggering amount of stale files going back to 2017, which I promptly nuked.
Now, with @greenjean's script, that does not happen any more.
My headless Chimaera VM does not have a */.dbus/session-bus/ directory.

All this to say that this looks like a dbus problem albeit (most probably) related to systemd.

Just a guess, a possibly educated one.

Best,

A.

Logs to /var/log/user.log

.

Well that's nicer and easier to find the entries than it is in syslog, I guess I need to read the logger man page more thoroughly. So it's logging in both places, that seems redundant, maybe I need to specify.

Users of the lightdm display manager will probably also see an accumulation of files in /var/lib/lightdm/.dbus/session-bus/

Sonofagun...nice find! I wonder if we can safely delete those on shutdown as well?

Interesting...much smaller accumulation of files in there than was in the other two folders.

Curiouser and curiouser...on my build partition where I make and snapshot Vuu-do, there are 21 files in that folder, and according to the properties tab, every single one of them was created at the same time, date, hour, even down to the same second. And that was last Wednesday the 17th at the exact same time a snapshot of Vuu-do (mini-ob-z) was started, but off by exactly an hour (that may be a daylight savings time discrepancy).

@fsmithred, this seems strange, no?

The other partitions have some files as well, but the dates are not all the same.