I tried to reomve / purge the mentioned applications (cinnamon screensaver, dnome screensaverâŠ) but that does not change anything.
In addition,I tried to find the destination by this cryptic number, but the destination is not found)
~$ dbus-send --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionCredentials string:'1.19656'
Error org.freedesktop.DBus.Error.NameHasNoOwner: Could not get credentials of name '1.19656': no such name
Does someone has a clue how I can find out what is the source of the messages?
The colon at the beginning is significant - it marks this as a unique connection name. Also be aware that there are two separate dbus instances, the system bus and the session bus. So you might want to try
Thank you for your quick reply, @hdd-gehrke!
I tried your corrected dbus-requests:
dbus-send --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionCredentials string:':1.53100'
Error org.freedesktop.DBus.Error.NameHasNoOwner: Could not get credentials of name ':1.53100': no such name
With d-feet I was not successfull as well, but I finally know why:
The credential string changes constantly (better it increments by one after all string values âcom.canonical.dbusmenuâ, âorg.gnome.Shell.Extensions.StreamControllerâ⊠are sent once.
Can it be that a âdbus-processâ is constantly restarting?
Do you know where this number is generated?
Usually, no. * If your system is running fine: These logs are just ânoise.â The app is simply checking if features like âprevent screen sleepâ or âshow tray iconâ are available. Since it canât find the specific service for your desktop, it will likely just skip that feature or use a generic fallback.
If an app is crashing: If a specific program fails immediately after these logs, it means the developer didnât handle the NameHasNoOwner error gracefully, and the app is crashing because it expected a service to be there.
It could either be a process that is constantly restarting (a process starts, tries to connect to several services through dbus, finds out that it canât, closes down because talking to those process is necessary for it, gets restarted possibly by systemd or through dbus; that seems to me like an honest mistake or a misconfiguration) or it could be that itâs one process that constantly connects to and disconnects from dbus (that seems almost malicious to me because I canât think of a sane reason to do so; might be just an error but would be a stupid thing to do âŠ). Either explanation fits the constantly increasing unique connection name.
A unique connection name is generated by the dbus-daemon and given to anything that connects to the bus and calls org.freedesktop.DBus.Hello().
and set the unique connection name to something that is a bit larger than the last observed value. With a bit of luck youâll get it after it crashes and gets a new unique connection name.
@hdd-gehrke Thank you for your ideas. Yesterday I already tried manually to make the dbus request with an upcoming number but I was not frequent enough.
Now with your script it looks like, the script is using the same number range. So the numbers are rising even much more frequently and I had no chance to get the right number.
I will now try to disable the user services to see if some of this services is causing thtrouble.
For the benefit of anybody reading this later: I didnât think of the fact that dbus-send also makes a new connection to the bus on every call. A much more promising approach would be to write a similar script in Python using something like python3-dbus; with that you would only make one connection for your script and could have a function that listens for the signal NameOwnerChanged and would be called by the bus every time a new name appears on the bus.