This question could sound be a bit provocative, so let me explain why I ask. In the process of testing the yet-to-be released Slint 15.0 based on Slackware 15.0 I have tried to start all desktops that will be provided[1] with a minimum content of ~.xinitrc, as follows:

• exec fvwm
• exec startlxq
• exec mate-session
• exec startplasma-x11
• wmaker
• exec startxfce

Please note that I did not include a dbus-launch command.

All desktops started without issue and the expected XDG variables were all properly set (thanks to the elogind PAM module if I understand correctly for XDG_RUNTIME_DIR), however something puzzles me:
DBUS_SESSION_ADDRESS was set in LXQt, MATE and XFCE, but not in FVWM, WMAKER an KDE. I do not know why dbus was launched in some desktops, but my main question is "what do the user misses without dbus" as after some (admittedly very short an superficial) testing the lack of an IPC didn't seem me to hurt.

As a side note loginctl seemed to work as expected in all cases.

[1]I did not test twm blackbox and fluxbox.

I cannot tell you exactly why but be aware that some applications start a dbus user session on their own, which gives a little bit of a odd behavior since a dbus system session is expected, but the applications still work more or less good, for example: If an application needs gnome-keyring. That may be the reason why you find a dbus session address set.

Without a DBUS notification service, window managers such as fvwm and wmaker will have problems with applications that use DBUS such as nm-applet and gvfs. For the user, nm-applet is slow to start and unresponsive while gvfs cannot handle the addition and removal of pluggable storage.

Apparently KDE Plasma does this independently.

All the different desktop environments seem to do their own "spin" on starting the desktop and session dbus. The 'startfvwm2' script will start a dbus on its own. Others like plasma do not start one, and require the user to start it in xinitrc or *.desktop file. I believe xfce4 also starts its own dbus IIRC from when I last tested that.

There's the system dbus, and then the user level session dbus. 'loginctl' is part of elogind and is a daemon that uses the system dbus for its messages. The system bus is started at boot with rc.messagebus and runs independant of desktop session dbus's.

The XDG directories are handled separately by pam_elogind, which is triggered at login/logout in the PAM stack, so that is all separate from dbus.

The session dbus is the other type of dbus, and gets started usually when a user starts a graphical session. As you see theres a lot of variation in how it starts between desktop types. Some distros have service managers to run it as well. The session dbus allows the desktop components to communicate, though different desktops use them to a varying amount.

If youre ever curious to see what is on the dbus during a session you can use 'qdbus' to print some information out about whats on the bus, and interact a bit (/usr/lib64/qt5/bin/qdbus if you have plasma installed). You will see stuff like power management, audio, notifications, screensavers, webbrowsers, etc type stuff on there, so I guess functionality between those things interacting breaks without it.

Edit: Just realized there's also 'busctl' on slackware that comes with elogind. Easier to interact and see what services are also available on dbus with that tool.

3 members found this post helpful.

I've been using fvwm without dbus for several years, and so far the only thing I've noticed not work is that my browser depends on it somehow to add website security exceptions.

I can live with that.

Thunar would use it to communicate with xfconf, i.e. without dbus, thunar will not read XML config file.
It'd start with all settings default, and it'd not remember any changes made in settings menu.
Firefox depends on dbus and would not even start without it. For GNOME components, it's an integral part of the system.

Otherwise, non freedesktop compliant stuff generally has no use for it.
For example, I use blackbox wm sometimes with no dbus lib at all and it works fine.

Thanks all and especially 0XBF for his very enlightening answer. I have found that qdbusviewer-qt5 comes very handy to check which processes currently use dbus, both at the system and session levels.

Next: as most major distributions now use dbus-broker which supersedes dbus and is more responsive as I have read, I will try to replace dbus by dbus-broker in Slint. There is a hurdle which is that its launcher depends on systemd, but only on its shared library at run time according to the packaging done by Arch (a build dep on a full systemd is mentioned, will check if it can be built without). So the plan is, stealing Arch's PKBUILDs:

• Build and install systemd-libs
• Try to build and install dbus-broker

I will request help from Artix if need be, as they do not use systemd but do use dbus-broker.

Will do a follow-up in this thread.

1 members found this post helpful.

I am aware of dbus-broker, but have never tried exploring how it builds or works. I see that it's in the Artix sources so I guess it builds without systemd. Artix uses different init systems that also provide service management, so I dont know how integrated into a service manager dbus-broker needs to be.

On a related note: I have experimented with running the session dbus on slackware more similar to a user service: starting and stopping at login and logout, instead of integrated into the xinitrc and desktop files. From that experience I can tell you that doing anything differently with session dbuses in slackware is a pain, since "dbus-launch" and "dbus-run-session" seem to get sprinkled around haphazardly.

Plasma is particularly bad at this, with each method of starting X11 or wayland plasma from xinit and .desktop files doing something differently. Sometimes they are intelligent and will check for a dbus, starting one if needed. Other times they will start a session dbus without checking first, leading to multiple session dbuses if you started one already in a different way. Then you find that other desktops launch a dbus in their actual "start<desktop>" script, though those ones usually are "smarter" in checking for an existing one first.

I guess this is the way that upstream provides their files so they are left as-is in slackware. Just be prepared to look through those files when you start seeing dbus instances started that you didnt want, if you go testing a different method of starting the session dbus.

3 members found this post helpful.

Follow up:

• Build and install systemd-libs: OK with the ugly custom script that I wrote for that (attached)
• Try to build and install dbus-broker: KO when trying to build it is says the not only libsystemd but also systemd is a run time dependency :\

Then I chatted with some Artix people on IRC: as they told me actually their dbus-broker (built without the launcher) is only used as dependency of at-spi2-core... (as an aside this is wrong, I have at-spi2-core 44.1 installed and Orca speaks to me). So, no luck unless/until someone writes a launcher for dbus-broker that does not depend on systemd.
Yes. I will look through of all these files and edit them as need be before releasing Slint64-15.0

EDIT: replaced the attachment by buid-libsystemd.sh.txt after correction.

Attached Files

build-libsystemd.sh.txt (927 Bytes, 7 views)

IMO DBUS is just more added crap that I dont want or need. But it's baked into the cake. Like systemd. But that's just my use case. And freedesktop.org - I don't like their direction or their philosophy.

1 members found this post helpful.

Fascinating topic, thanks for starting this, Didier. DBUS is a requirement in the BSDs too.

With all respect, I believe that is epic bad this installing of the libsystemd in a elogind-based distro. This is so wrong that makes puppies cry.

This will make various programs to pick systemd support at builtime instead of the proper elogind support, resulting in a predictably Royall mess. Because libelogind is a modified version of libsystemd. In few words: NEVER DO THIS.

In my humble opinion, the proper way is to port the victim program to use elogind and the associated libelogind - and usually is enough to mess with the build system. IF you can't do this, or the program fails to work properly with elogind, this means that's an exclusive systemd thingy and you should call a day.

1 members found this post helpful.

Huh? The DBUS is just a communication server, where various daemons registers their API, and the client programs use those APIs.

Is exactly what do the older than dirt Web APIs, but made under a local communication server.

What the programs talks over this DBUS? Many things. For example, the Skype may block the screen blanking while a video call is active, or KTorrent can shutdown the computer when finishes the downloading. Or it can block the computer sleeping until finishes.

Anyway, there are tons of things which are done over DBUS, specially when you use Plasma5 or any other decent DE. No, I do not talk about windows managers, BUT even while using a simple windows manager, the used applications may talk over DBUS. I.e. KTorrent with elogind for the power management.

What's is really sad is that looks like in Slackware is not yet a consistent way of managing the DBUS sessions.

1 members found this post helpful.

Well unless you bundle libsystemd in dbus-broker, or you put it in a "private" (for dbus-broker only) location. Anyway as I can't use libsystemd alone to make elogind happy, I have no reason to ship it in Slint (so far).

It is well known that the launcher (and only the launcher) of dbus-broker is a systemd thingy hence my experiments. So the only way would be to write from scratch an alternative launcher for dbus-broker, not dependent of systemd. This is well known, but nobody so far did it. I have neither the skills nor the time to do it, unfortunately.