KDE and dbus_enable

[ikevin8me]

I had just did a fresh installation of FreeBSD 13 and xorg+KDE. I deliberately left out "dbus_enable="YES" in the /etc/rc.conf (after finding out that it isn't really necessary as some users don't have it enabled). After rebooting the machine, I got a blank (black) screen with only a moving mouse pointer.

I then went to /etc/rc.conf and added "dbus_enable="YES" and rebooted. This time, I got the KDE environment with the options to reboot, shutdown, etc.

Then, I went to the /etc/rc.conf file and commented-out the "#dbus_enable="YES". And I rebooted. And, I still got the KDE environment but without the options to reboot (no shutdown, reboot, etc.)

So, to summarize:

1. first reboot just after install without dbus_enable, I could not start KDE - blank screen.
2. added "dbus_enable="YES", rebooted and I got KDE, with shutdown/reboot options.
3. commented-out "#dbus_enable="YES" and got KDE, without shutdown/reboot options.

So, my question is:
By just enabling dbus_enable once, and then disabling it, what difference is it making to the system (config files, etc.)?

 

[tux2bsd]

It's not making a difference to the system, just a thing you're turning on or off.

fyi you can do sysrc dbus_enable="YES" to toggle (e.g. NO) values in rc.conf. sysrc followed by the line you'd edit. More useful when scripting stuff though.

 

[mer]

A fresh install with dbus_enable not YES means /usr/local/etc/rc.d/dbus does not run.
"So what, I already know that" I hear you ask.
Well, if you look at the service file for dbus, take a look at the dbus_prestart() function. A very important line is the one that says:
/usr/local/bin/dbus-uuidgen --ensure

That creates a file /var/lib/dbus/machine-id with a randomly generated GUID.
That function also does mkdir -p /var/run/dbus

KDE and a lot of other things check for the existence of that file and do a dbus-uuidgen --get to pull the value and do stuff with that value.

Normally that command is run on installation of the dbus package, so in theory, one should be able to just install the dbus package, have it generate the guid and never actually run the dbus service.

Hope that answers OP's question.

 

[ikevin8me]

That’s exactly what I need to know. Thanks!

 

[Tieks]

... one should be able to just install the dbus package, have it generate the guid and never actually run the dbus service.

Please note that several other ports do need dbus for messaging. And that dbus requires some version of Python and, and...

 

[mer]

Please note that several other ports do need dbus for messaging. And that dbus requires some version of Python and, and...

Of course, but that is beyond the scope of the OP's question.

One of the most common uses of dbus messaging is saving of config/preference changes. Application running, you change default color (or colour), those changes may get saved by the app sending a dbus message that winds up changing $HOME/.config/Application/config.
If dbus service is not running, a log would indicate "Application tried to send dbus message failed" and your changes don't get saved, but everything still runs.
Start Chromium or Firefox from a term window, you'll often times see that kind of output logged to the window.
An interesting point is that "dbus" has long been considered a security risk and folks often don't run the dbus service. I don't.
BUT: a lot of applications "are nice and call dbus-launch" for you so you have an instance running as a user instead of as root. Things like GIMP and other "Gnome" programs seem to do this.

 

[Tieks]

You're right. Imo dbus is one of these Linux innovations that will be abandonned after a number of years, most for good reasons. A similar case is HAL (hardware abstraction layer). But where HAL is practically gone by now, dbus is not that far yet. It still is a runtime dependency in a number of ports. So you can try to run KDE without dbus, but it may pop up again after the next install.
And to answer the question that inevitabley will come next: No, systemd not yet.

 

[mer]

No, systemd not yet.

Not ever.
I think it's been sidetone talking about configuring things with only BSD-isms. I don't know if there is/are config knobs in KDE builds to disable dbus (you'd need to start at KDE-meta and then all the bits and pieces).

That's what is/was nice about Lumina: designed from day one to use BSD stuff. Author did the best a one-man shop could do, but writing Window managers isn't trivial.

A quick glance at a couple of applications I regularly use (firefox, trojita) show explicit dependencies on dbus, so in theory one could make a flavor say "-nodbus".

Edit:
Quick experiement. I do not have dbus running as a service, some applications (Firefox) kick off dbus-launch and dbus-daemon. I killled those processes, then renamed the executable so they can't be run. Firefox and others seem to be more responsive, perhaps they aren't doing dbus handshakes anymore.

 

[Deleted member 30996]

I get it with Gimp and dbus is runnin' but I don't worry about it.

 

[ikevin8me]

I now have 'dbus_enable="NO"' and I confirm that the "shutdown" menu options are not available in KDE. However, I see processes like "dbus-launch" and "dbus-daemon" running (showing in top). I'm curious why are they running and what are they doing?

Edit:
Quick experiement. I do not have dbus running as a service, some applications (Firefox) kick off dbus-launch and dbus-daemon. I killled those processes, then renamed the executable so they can't be run. Firefox and others seem to be more responsive, perhaps they aren't doing dbus handshakes anymore.

Is this necessary to rename them so they can't run?

 

[mer]

You see them running (should be under your userid) because one of the applications started them. Firefox does, so do a bunch of other things.

That is why I just renamed them, since I was just experimenting a quick check on what functionality breaks when they aren't started. Don't try to pkg delete dbus because then you may wind up removing more than you want.

 

[SirDice]

However, I see processes like "dbus-launch" and "dbus-daemon" running (showing in top). I'm curious why are they running and what are they doing?

DBus consists of multiple parts. There a system service, that's started with dbus_enable. Then there are application side DBus processes, those use the DBus protocol to talk to each other and the system. DBus is basically an advanced version of IPC. Many modern applications use DBus to talk to other parts of the desktop and/or system itself.

D-Bus - Wikipedia

en.wikipedia.org

 

[Cath O'Deray]

I now have 'dbus_enable="NO"' …

You might do better to have it enabled, as is normal for KDE Plasma.

… blank (black) screen with only a moving mouse pointer. …

Sometimes, not exclusively, found with VirtualBox:

vbox - VirtualBox guests: black screen with X pointer; non-appearance of the desktop environment; non-starts of the DE (reappearance of SDDM)

Spun off from posts by other users under (after the original issue was solved). Host: % date ; uptime ; uname -v Sat 12 Jun 2021 14:47:02 BST 2:47p.m. up 3:34, 6 users, load averages: 1.56, 1.33, 1.41 FreeBSD 14.0-CURRENT #98 main-n247326-2349cda44fe: Sat Jun 12 08:19:48 BST 2021...

forums.freebsd.org

– in my experience, this rarely or never happens if the quick start is followed. https://community.kde.org/FreeBSD/Setup#Quick_start (1–4, 1–5).