Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: is X11 now a days connecting to dbus without user intervention? (Read 1170 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

is X11 now a days connecting to dbus without user intervention?

Hello !

It used to be that one either had to source all shell scripts from /etc/X11/xinit/xinitrc.d/ or at least source the one including dbus stuff like /etc/X11/xinit/xinitrc.d/30-dbus:

Code: [Select]
if test x"$DBUS_SESSION_BUS_ADDRESS" = x""; then
   dbuslaunch=`which dbus-launch`
   if test x"$dbuslaunch" != x"" -a x"$dbuslaunch" != x"no"; then
       eval `$dbuslaunch --sh-syntax --exit-with-session`
   fi
   unset dbuslaunch
fi

Or as later, one could just use dbus-run like exec dbus-run-session <wm>.  Or use the not available on artix I guess and still part of those shell script to source, /etc/X11/xinit/xinitrc.d/50-systemd-user.sh:

Code: [Select]
systemctl --user import-environment DISPLAY XAUTHORITY
if command -v dbus-update-activation-environment >/dev/null 2>&1; then
    dbus-update-activation-environment DISPLAY XAUTHORITY
fi

Notice the dinit script in there, /etc/X11/xinit/xinitrc.d/01-dinit-env.sh:

Code: [Select]
#!/bin/sh

# we want to make these available in the user service activation environment
dinitctl setenv DISPLAY XAUTHORITY > /dev/null 2>&1 || :

Doesn't include any dbus stuff.  And nothing in there calls for any dbus stuff either:

Code: [Select]
% ls /etc/X11/xinit/xinitrc.d/
01-dinit-env.sh*  40-libcanberra-gtk-module.sh*  80xapp-gtk3-module.sh*  90-xdg-user-dirs.sh*

% grep -ri dbus /etc/X11/xinit/xinitrc.d/
%

I'm not using any dbus stuff on my ~/.xinitrc neither I'm calling i3 with dbus-run neither dbus-launch session commands.

And yet, withing i3 on top of X11 started with startx I still see dbus stuff just running for X11:

Code: [Select]
% ps -auxww | grep dbus
dbus       892  0.0  0.0   5872  2868 ?        Ss   Jul18   0:01 /usr/bin/dbus-daemon --system --nofork --nopidfile --print-address=4
root       895  0.0  0.0 415824  9096 ?        Ssl  Jul18   0:41 /usr/bin/thermald --no-daemon --dbus-enable
<my_user> 27342  0.0  0.0   9744  5812 pts/4    S+   16:31   0:00 grep -Es --color=auto dbus
<my_user> 28313  0.0  0.0   4548  1476 tty1     S    05:28   0:00 dbus-launch --autolaunch=3e04e041f27fd75e86c6b3f06569715c --binary-syntax --close-stderr
<my_user> 28314  0.0  0.0   5660  1940 ?        Ss   05:28   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
<my_user> 28396  0.0  0.0   5508  3064 ?        S    05:28   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/<my_UID>/at-spi/bus_0

Where did that <my_user> and <my_UID> stuff come from?  I'm not calling for any dbus stuff.  BTW, I notice on the Arch Xinit Wiki it's mentioned one needs to at least source the /etc/X11/xinit/xinitrc.d/ stuff, I guess to load the systemd dbus stuff, but I don't see anything dbus related there that I'm aware of.  So I'm clueless where that stuff is coming from.  Out of my own crazyness I was starting to believe that dunst was working without dbus now, just to get disappointed at myself believing I was running without dbus.

BTW, this doesn't happen on plain bash login session on console.  When I haven't launched X11 yet, and I do the same grep command, nothing shows up.  So this is spawned when X11 gets launched.  BTW:

Code: [Select]
% grep -ri dbus /etc/X11/
%

There's nothing in there I could relate to dbus either.

So now a days there's no way to run a X11 session without dbus, right?  Is that it?  And also, there's no longer a need to even start the window manage with dbus-run-session or any similar command since session gets somehow auto-connected to the dbus socket and stuff somehow.

Ohh, I don't have elogind installed, I got rid of it when starting to use seatd:

Code: [Select]
% pacman -Qs elogind
local/libelogind 255.17-2
    elogind client libraries
local/seatd-dinit 20230412-3 (dinit-world)
    dinit service scripts for seatd

And I'm also not calling polkit either to favor seatd, and I actually re-built pcsclite so it no longer depends on polkit sruff anymore:

Code: [Select]
  local meson_options=(
    -D libsystemd=false
    -D libudev=true
    -D polkit=false
    -D serial=true
  )

Just to make sure.  If there's not way without dbus, should I then use dbus-run-session for better integration, or this automatic dbus spawn is enough not to have something half way?  Or is there something that can be tweaked?

I noticed thermald, bluetoothd and pcscd which I currently have enabled are all dependent on dbus.  I can't get rid of pcscd since I depend on my yubikey for work related stuff, though I can rebuild stuff, but I'm afraid those guys need dbus for IPC with stuff using the yubikey like the browser.  Doe this also mean I can't get rid of dbus?

Sorry for the long set of questions.

Re: is X11 now a days connecting to dbus without user intervention?

Reply #1 –
You can run X without dbus but a lot of DE's need it to function properly. At least I'm fairly sure that's the case.
I use KDE and whereas I used to have to start a user dbus myself, when running startplasma-x11, now it just happens.

Re: is X11 now a days connecting to dbus without user intervention?

Reply #2 –
Not long ago, I tried replacing dbus with fake-dbus, a dummy dbus where the functions do nothing and just return NULLs. After some tweaking, I got xserver to launch, but it immediatelly segfaulted. I'm only using dwm.

I interpreted this experiment to mean that the X shipped by Artix expects dbus and even interacts with it from the start. The author of fake-dbus is a Gentoo user and says he is able to use X without a real dbus, but then I guess X has to be compiled with a different configuration.

I have not looked at the xserver source code, though, which is where the answer would lie. There's also some discussion about "dropping dbus dependency" on Xlibre github.

Edit: also using seatd instead of logind (but according to the init script, seatd needs dbus).

Re: is X11 now a days connecting to dbus without user intervention?

Reply #3 –
FWIW - I don't use a DE but even with just using wmaker I think applications depend on dbus.

Quote
flatbush:[ruben]:~$ sudo pacman -Qi dbus
Name            : dbus
Version         : 1.16.2-1.1
Description     : Freedesktop.org message bus system
Architecture    : x86_64
URL             : https://www.freedesktop.org/wiki/Software/dbus/
Licenses        : AFL-2.1 OR GPL-2.0-or-later
Groups          : None
Provides        : libdbus  libdbus-1.so=3-64
Depends On      : audit  expat  glibc  libcap-ng  libelogind  libaudit.so=1-64
                  libcap-ng.so=0-64  libexpat.so=1-64
Optional Deps   : None
Required By     : at-spi2-core  avahi  colord  cups  dbus-glib  dbus-openrc
                  elogind  emacs  firefox  fluidsynth  hplip  jack2
                  libcupsfilters  libdecor  libnvme  libpcap  libpulse
                  libreoffice-fresh  libvlc  light-locker  openrc-settingsd
                  pipewire  python-dbus  qt6-base  qt6-webengine  rtkit
                  subversion  thunderbird  udisks2  ungoogled-chromium
                  vlc-plugin-dbus  vlc-plugin-dbus-screensaver
                  vlc-plugin-kwallet  wpa_supplicant  xorg-server  zbar
Optional For    : None
Conflicts With  : libdbus
Replaces        : libdbus
Installed Size  : 906.65 KiB
Packager        : Artoo <[email protected]>
Build Date      : Wed 12 Mar 2025 10:06:57 AM EDT
Install Date    : Fri 21 Mar 2025 10:20:01 AM EDT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

The big one here for me is CUPS.  I don't like it, but there it is.

Depends On      : acl  pam  libcups>=2.4.12  cups-filters  dbus  systemd  systemd-libs
                  libpaper  hicolor-icon-theme  glibc  gcc-libs  avahi  gnutls


Kind of cute that pacman reports that cups depends on systemd.  Obviously there is some inconsistancy in this report frpm pacman

flatbush:[ruben]:~$ sudo pacman -Si cups

Re: is X11 now a days connecting to dbus without user intervention?

Reply #4 –
maybe this is the reason:
sudo pacman -Si cups-openrc

flatbush:[ruben]:~$ sudo pacman -Si cups-openrc
[sudo] password for ruben:
Repository      : world
Name            : cups-openrc
Version         : 20210505-2
Description     : OpenRC cups init script
Architecture    : any
URL             : https://gitea.artixlinux.org/artixlinux/packages-openrc
Licenses        : GPL2
Groups          : openrc-world
Provides        : init-cups
Depends On      : cups  openrc  avahi-openrc
Optional Deps   : None
Conflicts With  : init-cups
Replaces        : None
Download Size   : 2.84 KiB
Installed Size  : 0.61 KiB
Packager        : Artix Build Bot <[email protected]>
Build Date      : Thu 06 May 2021 06:23:33 AM EDT
Validated By    : MD5 Sum  SHA-256 Sum  Signature


No dbus?  But it has Ahavi which depends on dbus.

Re: is X11 now a days connecting to dbus without user intervention?

Reply #5 –
This is very off original topic, but do you have Arch repos enabled by chance? Because I get
Code: [Select]
$ pacman -Si cups | grep Depe
Depends On      : acl  pam  libcups>=2.4.12  cups-filters  dbus  libudev  libpaper  hicolor-icon-theme  glibc  gcc-libs  avahi  gnutls
(No systemd.)

Re: is X11 now a days connecting to dbus without user intervention?

Reply #6 –
Quote from: lotuskip – on
This is very off original topic, but do you have Arch repos enabled by chance? Because I get
Code: [Select]
$ pacman -Si cups | grep Depe
Depends On      : acl  pam  libcups>=2.4.12  cups-filters  dbus  libudev  libpaper  hicolor-icon-theme  glibc  gcc-libs  avahi  gnutls
(No systemd.)


I am sorry for dragging this off topic.  It is related only to the degree that it was asked if X11 ran dbus, which is no.  DEs do so, and I pointed out that individual applications also depend on dbus, sometimes to my disliking. 

I do not have arch repos installed.  There is a cups in extra that depends on systemd
extra I have turned on, evidently.

FWIW - it if hard to grep because the output is multilined.  multilined egrep is too much for my mind to bend this morning :)

Re: is X11 now a days connecting to dbus without user intervention?

Reply #7 –
Off topic:
Spoiler (click to show/hide)

On topic:
Here's that discussion I mentioned on Xorg requiring dbus.

Re: is X11 now a days connecting to dbus without user intervention?

Reply #8 –
Thanks for the link !

Just so you know, as 25.0.0.5 is still having dpms issues on my work laptop, I had to build xlibre, and I just built it without systemd_logind:

Code: [Select]
    -D systemd_logind=false

No issues without logind (I don't use it any ways).  When I created the post I was testing 25.0.0.5.  And even without systemd_logind, X11 still spawns a bunch of dbus stuff.

I'm aware of many applications looking for dbus IPC, though mostly looking for configuration stuff, particularly on gnome, because apparently reading config files or accessing their DB via file is a thing a of the past.  as mentioned, in my system thermald, bluetoothd and pcscd depend on dbus.  I'm not sure if otherwise they would not behave as expected.  It used to be linux didn't include any dbus stuff but now a days it does thanks to that mentioned corp.  So I don't know if any of those services would work without dbus.

Now, to make things more confusing, at least to me, as mentioned I'm not calling any dbus stuff before or while starting i3, which on the x11 logs which can be confirmed by seeing how some apps complain about not having the dbus env vars available, for example an electron one:

Code: [Select]
[17322:0721/202425.633630:ERROR:dbus/bus.cc:408] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

I really don't care much about those failures, since they don't really seem to affect.  Not sure if printing (cups), bluetooth and thermald  would malfunction or actually not work at all due to the lack of dbus.  But if not using full DEs, I can't think of anything breaking on the GUI environment just because of the lack of dbus.

So I guess to prevent those failures I could start i3 with dbus-run-session i3, but it's not really required, not sure if it's related to the fact I'm not using elogind neither polkit.  And X11 is still spawning several dbus processes which I don't know why or with what purpose since applications seem unable to connect without the env var.  Now besides the processes I mentioned before, I see a few more:

Code: [Select]
<my_user>  9895  0.0  0.0   2836  1828 ?        S    18:00   0:00 /usr/bin/bwrap --args 85 -- /usr/bin/xdg-dbus-proxy --args=79
<my_user>  9896  0.0  0.0   2844  1320 ?        S    18:00   0:00 /usr/bin/bwrap --args 85 -- /usr/bin/xdg-dbus-proxy --args=79
<my_user>  9897  0.0  0.0 235332  9208 ?        Sl   18:00   0:00 /usr/bin/xdg-dbus-proxy --args=79
<my_user> 12922  0.0  0.0   2836  1828 ?        S    14:20   0:00 /usr/bin/bwrap --args 105 -- /usr/bin/xdg-dbus-proxy --args=100
<my_user> 12923  0.0  0.0   2844  1316 ?        S    14:20   0:00 /usr/bin/bwrap --args 105 -- /usr/bin/xdg-dbus-proxy --args=100
<my_user> 12924  0.0  0.0 235332  9132 ?        Sl   14:20   0:00 /usr/bin/xdg-dbus-proxy --args=100

Bottom line, disabling systemd_logind doesn't prevent x11 to work well on artix.  Doing so doesn't prevent dbus to be spawned multiple times.  Even though the WM/DE gets launched without knowledge of where the dbus stuff is, the x11 dbus processes still get spawned...

For now I guess I can continue what I'm doing.  I guess it'd be nice to get rid of dbus, but dinit services depending on the dbus will summon it any ways.  I can try editing those services by hand and see what happens, but not now.  I'm surprised services are dbus dependent as well and not just GUI applications.  I'll keep an eye on the x11 discussion, it seems quite interesting so far.  I hope dbus can be made optional as well, just like systemd/logind stuff is.

Thanks !

Re: is X11 now a days connecting to dbus without user intervention?

Reply #9 –
Ouch, just found the reason electron apps URLs were failing to launch on FF/Librewolf and always failing with FF/Librewolf already running was the lack of calling the WM with exec dbus-run-session <WM> .  At the off. there's an axis atmos one I can't even copy/paste the URL since it depends on launching the auth through some web browser options, so that was even worse.  Sadly as mentioned before by others, a bunch of software now a days rely on dbus to work properly, :(  So I guess no full joy without it...