Setup xinitrc (startx) and connect to DBUS (set DBUS_SESSION_BUS_ADDRESS) on Debian 11
Published 2021-10-11 on Anjan's Homepage
I recently installed Debian 11 on a workstation and the .xinitrc
I usually use on Gentoo (with openrc) and Alpine (also openrc) did not properly setup dbus ($DBUS_SESSION_BUS_ADDRESS
env variable was empty).
I tried putting export $(dbus-launch)
in my .xinitrc
as stackexchange recommended but this did not fix the dbus environmental variables being unset.
$DBUS_SESSION_BUS_ADDRESS
not being set is problematic as pinentry-gnome3 will not launch.
The fix comes from examining the example xinitrc
with cat /etc/X11/xinit/xinitrc
on Debian:
#!/bin/sh # /etc/X11/xinit/xinitrc # # global xinitrc file, used by all X sessions started by xinit (startx) # invoke global X session script . /etc/X11/Xsession
The global X session script runs a number of scripts located in /etc/X11/Xsession.d/
.
Notably, to set the dbus environmental variables, /etc/X11/Xsession
runs /etc/X11/Xsession.d/20dbus_xdg-runtime
:
# vim:set ft=sh sw=2 sts=2 et: if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] && [ -n "$XDG_RUNTIME_DIR" ] && \ [ "$XDG_RUNTIME_DIR" = "/run/user/`id -u`" ] && \ [ -S "$XDG_RUNTIME_DIR/bus" ]; then # We are under systemd-logind or something remarkably similar, and # a user-session socket has already been set up. # # Be nice to non-libdbus, non-sd-bus implementations by using # that as the session bus address in the environment. The check for # XDG_RUNTIME_DIR = "/run/user/`id -u`" is because we know that # form of the address, from systemd-logind, doesn't need escaping, # whereas arbitrary addresses might. DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" export DBUS_SESSION_BUS_ADDRESS fi if [ -x "/usr/bin/dbus-update-activation-environment" ]; then # tell dbus-daemon --session (and systemd --user, if running) # to put a minimal subset of the Xsession's environment in activated # services' environments dbus-update-activation-environment --verbose --systemd \ DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY fi
dbus-update-activation-environment uses systemd to set the environmental variables:
–systemd Set environment variables for systemd user services as well as for traditional D-Bus session services.
Source: dbus-update-activation-environment manpage
To recap, if you dont have a display manager and want to use startx, you should use the example xinitrc (/etc/X11/xinit/xinitrc
) that will setup a lot of stuff that you probably need in a Xorg session.
But, you likely have some custom programs that you need to launch before your window manager.
The default Xsession script allows for user defined script to ran (grep XSESSION /etc/X11/Xsession
):
USERXSESSION=$HOME/.xsession USERXSESSIONRC=$HOME/.xsessionrc ALTUSERXSESSION=$HOME/.Xsession
Summary of Fix
As such, we can move our old xinitrc that launches programs (dwm, sxhkd, redshift, mpd, etc) to $HOME/.xsession
and startx
will run /etc/X11/xinit/xinitrc
It is recommended to use .xsession
over .xsessionrc
1 , 2.
mv $HOME/.xinitrc $HOME/.xsession
Note: the file $HOME/.xinitrc
should not exist so that /etc/X11/xinit/xinitrc
is ran.
Finally! We have dwm working with dbus. More importantly, as the distro maintainers determine other boilerplate commands that need to be run in xinitrc, your setup will automatically load those commands.
Footnotes:
.xsessionrc
is read before debian’s default Xsession and .xsession
will be read after. If you have conflicting settings, yours could get overridden. https://wiki.debian.org/Xsession
Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~anjan/public-inbox@lists.sr.ht [mailing list etiquette]
Articles from blogs I follow around the net
These articles/blogs do not represent my own opinions or views.Text processing on the Command Line - sharing my tools
Text processing on the command line - sharing my tools Introduction I'm quite fond of the command-line and spend a larger chunk of my life in a terminal emulator than I dare admit. I try to embrace the unix philosophy of using tools that "do one thing…
via Proycon's website July 7, 2024Linux phones are not automatically secure
A common point in the Linux community is that escaping the walled garden of ecosystems like Android or iOS is already a means to higher security. Having no contact with Google or Apple servers ever again, nor cloud providers ever snooping on your private …
via TuxPhones - Linux phones, tablets and portable devices January 25, 2023Generated by openring