You are not logged in.
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
$
That means your machine-id is fixed. The patch changing the machine-id works fine if that file does not exist. I don't have this file on my Daedalus and changing ids.
Last edited by rolfie (2025-09-18 21:08:48)
Offline
No not the /var/lib/dbus/machine-id file, I specifically mean /etc/machine-id which is a different file..located in /etc...lol. You shouldn't have one but if you do it might be an issue.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
@Rolfie
... patch changing the machine-id works fine if that file does not exist.
But it does ...
$ ls -l /etc/machine-id
-r--r--r-- 1 root root 33 Dec 13 2017 /etc/machine-id
$
And then the patch does not work.
@greenjeans
No not the /var/lib/dbus/machine-id file ...
Right ...
I knew which one you were referring to because I had both seen it and remembered that I had seen it.
But, as you can gather *...
See the date and the attributes?
It has probably been there since my first Devuan Linux installation, Jesse.
The patch evidently did not act on an existing machine-id and so it remained static.
I'll nuke it, see what happens after a few reboots and report back, later or early tomorrow.
Sorry about the distraction. 8^/
Best,
A.
Offline
Yeah that should change things Altoid, from the mountain of dbus documentation i've been reading today the presence of /etc/machine-id will stop uuidgen from generating new id's. So that seems like the issue in your case. The /etc/machine-id file is some systemd hooha, may have been a leftover from the very early days.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... presence of /etc/machine-id will stop uuidgen from generating new id's.
Yes, that was it.
But clearing out all the files in /.dbus/session-bus and rebooting twice got me this:
$ ls -h -l ~/.dbus/session-bus
total 8.0K
-rw-r--r-- 1 groucho groucho 462 Sep 18 19:15 aa86e5c7c1dc0ddb9ce2992a68cc8415-0
-rw-r--r-- 1 groucho groucho 462 Sep 18 19:08 d843ea5611c4fca72eb6d57968cc81d2-0
$
Patch now works but it does not serve any purpose if the previous id file is also there.
And I'll have a huge collection of session-bus files in no time.
Maybe deleting the file on shutdown with a script would do the trick?
I saw an example today, have to look for it.
Best,
A.
Offline
Maybe deleting the file on shutdown with a script would do the trick?
That's my first thought as well, but it would be a band-aid...be nicer if we could mod the behavior of whatever is creating/updating those folders though.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
I have not seen anyone (yet) report that their system is actually working as intended. ie: creating a new machine-id at boot.
Mine does it, this is the last time the machine was booted.
root@9600k:~# ls -l /var/lib/dbus/machine-id
-rw-r--r-- 1 root root 33 Sep 12 15:17 /var/lib/dbus/machine-id
Only it does not create the files everyone else talks about in the .dbus directories. Not like I care much everything works like it should without them.
Offline
There seem st be a lot of confusion in this thread about what a 'machine id' is and what a 'dbus session id' is. They are not the same thing despite dbus using the machine id as a unique but determinable temporary filename.
The reason '~/.dbus/session-bus/' fills up is evidence that the machine id is changing. Under systemd the machine id is never supposed to be changed so the filename never changes and the contents are simply overwritten.
NB This is also why you should avoid changing the machine id once logged in, it can have side-effects on dbus.
root@localhost:~# cat ~/.bash_logout
rm -f ~/.dbus/session-bus/*
Offline
Hello:
... what a 'machine id' is and what a 'dbus session id' is.
They are not the same thing ...
No, I get it.
The machine-id is used by .dbus.
The problem was having a fixed one, so I nuked /etc/machine-id.
Now I get a different one after every boot.
Which is what the patch mentioned in the ASCII release notes was for.
root@localhost:~# cat ~/.bash_logout
rm -f ~/.dbus/session-bus/*
Right.
That would (?) purge the random generated machine-id at every shutdown, solving the problem of the accumulation of files in ~/.dbus/session-bus.
But ...
That it is not what I see in my Daedalus installation:
$ cat ~/.bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.
# when leaving the console clear the screen to increase privacy
if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
$
[root@devuan ~]# cat ~/.bash_logout
cat: /root/.bash_logout: No such file or directory
[root@devuan ~]#
^^^^ same as /etc/skel/.bash_logout
Maybe manually adding the script would do it?
There is a thread here at Dev1 related to ~/.bash_logout:
https://dev1galaxy.org/viewtopic.php?id=5559
https://bugs.debian.org/cgi-bin/bugrepo … =%23331504
EDIT: agetty(8) clears the screen itself by default so presumably /etc/skel/.bash_logout was added when it didn't do that.
Now, if this is right and agetty clears the screen by default, ~/.bash_logout would not be needed?
Thanks for your input.
Best,
A.
Last edited by Altoid (2025-09-19 11:54:40)
Offline
I removed /etc/machine-id and now have the changing machine id - and the same accumulating files problem as others. Yeah! I don't reboot often and have a daily cleanup script that can take care of this so no big deal. (~/.config/session/ is another place that you might look for bloat).
My system dates back to Debian Stretch and was converted from Bullseye to Chimaera (and is now Excalibur) so it did use to run systemd. I use lightdm & Xfce.
Offline
At the link I posted earlier about machine-id, the author posted an init script for sysvinit that would manually rm both /etc/machine-id and var/lib/dbus/machine-id at shutdown/reboot, thus effectively doing what Devuan is doing natively and that's changing the id on every boot.
Our issue is different, but was wondering if the same method could be used to clear the user's and root's .dbus/session-bus files when you shut down? I've never messed with making init scripts, nor modding them, so I don't know squat, but I took the author's script and made what seemed like proper changes to it. If someone more knowledgeable could take a look at it and see if it's useful that would be great, and also wondering if there's a better method?
EDIT: That was ugly, working on something better right now...moar man pages and docs to read, lol!.
Last edited by greenjeans (2025-09-19 16:24:12)
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... removed /etc/machine-id and now have the changing machine id - and the same accumulating files ...
Exactly the same in my case.
(~/.config/session/ is another place that you might look for bloat).
No, I don't have that directory in my system:
$ cd .config/session
bash: cd: .config/session: No such file or directory
$
... an init script for sysvinit that would ...
Yes ...
root@localhost:~# cat ~/.bash_logout rm -f ~/.dbus/session-bus/*
It would seem that g4sra has (?) this ^^^^ script in his system.
But it is in the root directory and they have not said if it is part of the installation or added post-install.
Maybe he will drop by and shed some light on that.
Then there's the comment by HoAS (see link in previous post).
Best,
A.
Offline
Okay, this seems better, but again i'm a newb at init scripts, i'm willing to test this though so i'll see later today unless somebody more knowledgeable sees a flaw, if so please speak up! This cleans the folders, also rm's /etc/machine-id if it exists (in the case of migrations or legacy holdovers) adds logging (var/log/syslog) and is to spec for init scripts protocol as near as I can tell:
#!/bin/sh
### BEGIN INIT INFO
# Provides: rm-machineid
# Required-Start: $remote_fs
# Required-Stop: $local_fs
# Default-Start:
# Default-Stop: 0 6
# Short-Description: Remove dbus session-bus files on shutdown
# Description: Cleans ~/.dbus/session-bus and /root/.dbus/session-bus, plus /etc/machine-id for migrated systems
### END INIT INFO
set -e
PATH=/sbin:/usr/sbin:/bin:/usr/bin
NAME=rm-machineid
DESC="dbus session-bus cleanup"
do_stop() {
echo "$DESC: removing session-bus files" | logger -t $NAME
# Remove /etc/machine-id for Debian migrations or legacy Devuan installs
if [ -f /etc/machine-id ]; then
rm -f /etc/machine-id
logger -t $NAME "Removed /etc/machine-id (migration/legacy cleanup)"
fi
# Clean root's session-bus dir
if [ -d /root/.dbus/session-bus ]; then
rm -f /root/.dbus/session-bus/*
logger -t $NAME "Cleaned /root/.dbus/session-bus"
fi
# Clean all user home session-bus dirs
for userhome in /home/*; do
if [ -d "$userhome/.dbus/session-bus" ]; then
rm -f "$userhome/.dbus/session-bus"/*
logger -t $NAME "Cleaned $userhome/.dbus/session-bus"
fi
done
}
case "$1" in
start)
# No-op for start
;;
stop)
do_stop
;;
restart|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
*)
echo "Usage: $NAME {start|stop}" >&2
exit 3
;;
esac
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... unless somebody more knowledgeable sees a flaw ...
That certainly would not be me, so I cannot comment on it save to say that logging is a great idea.
What I can comment on, without any reservation, is your commitment to getting the problem solved.
And extend a heartfelt thank you for all the work you have put into doing so.
Kudos to you.
Best,
A.
Last edited by Altoid (2025-09-19 17:49:17)
Offline
Shucks...thanks my friend for the kind words! And right back at you, it wouldn't be the same around here without you.
So I tested the script, installed it into another partition running Vuu-do openbox-mini and shutdown/rebooted multiple times and it's working perfectly so far. Seems like a nice workaround that preserves Devuan's unique functionality in this area.
vuudo rm-machineid: dbus session-bus cleanup: removing session-bus files
vuudo rm-machineid: Cleaned /root/.dbus/session-bus
vuudo rm-machineid: Cleaned /home/vuudo/.dbus/session-bus
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... thanks ...
You're welcome.
... tested the script ...
Great.
... preserves Devuan's unique functionality
Indeed ...
This machine-id is thing is inextricably linked / related to systemd and as such should be curtailed.
Q: where should the script go?
Best,
A.
Last edited by Altoid (2025-09-19 23:39:03)
Offline
Well I don't want to urge anybody to install this until we can get some more knowledgeable eyeballs on it.
That being said I just ran another test on a different partition and it worked just fine once again.
The script itself should be named rm-machineid and installed in /etc/init.d/. You need to make sure root owns it and that it's executable.
Then in terminal, su-to-root and:
update-rc.d rm-machineid defaults 00
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... named rm-machineid ...
... in /etc/init.d/.
... root owns it and that it's executable.
... su-to-root and: update-rc.d rm-machineid defaults 00
Done.
From what I can see, works as advertised. 8^)
Logs to /var/log/user.log.
--- snip ---
Sep 19 18:28:03 devuan shutdown[11658]: shutting down for system halt
Sep 19 18:28:03 devuan rm-machineid: dbus session-bus cleanup: removing session-bus files
Sep 19 18:28:03 devuan rm-machineid: Cleaned /root/.dbus/session-bus
Sep 19 18:28:03 devuan rm-machineid: Cleaned /home/groucho/.dbus/session-bus
--- snip ---
Good job.
Best,
A.
Last edited by Altoid (2025-09-19 21:58:40)
Offline
Users of the lightdm display manager will probably also see an accumulation of files in /var/lib/lightdm/.dbus/session-bus/
Last edited by User479 (2025-09-22 21:36:33)
Offline
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.
Last edited by greenjeans (2025-09-23 22:30:21)
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
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.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Hello:
... smaller accumulation of files in there ...
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.
Offline
Hello:
... easier to find the entries than it is in syslog ...
I agree.
syslog is a mess to look in but lets thank the IT gods for being able to do so.
... read the logger man page ...
... logging in both places, that seems redundant ...
Hmm ...
Why not just to dmesg?
Best,
A.
Offline
Greenjeans: that is weird about the 21 files with the same time/date. I have no ideas about that.
This will nuke them all:
find / -type f -wholename "*.dbus/session-bus/*" -exec rm {} \;
Offline
This is odd: although my Excalibur system is showing the same behavior that everyone everyone describes here, my Ceres system completely lacks the file at /etc/default/dbus. Nonetheless, dbus is definitely installed and running. I'm also missing /etc/machine-id.
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.
Offline