I'm trying to use "systemd --user" to handle daemons that prefer being run as a user like PulseAudio and MPD.
However, every time I launch "systemd --user" from the console (since I login through the TTY and sometimes don't start a WM), it brings up this error without fail:
Failed to open private bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
(Exporting DISPLAY still crashes it)
PulseAudio will work, and MPD will work after logging out & back in, but I'm looking to figure out what is causing these problems with dbus. I've followed what I could from systemd/user ArchWiki.
At this point I'm just wondering how others are getting PulseAudio and other user daemons going automatically for non-X sessions.
It says it can't autolaunch, so do it manually. See man pages for dbus-launch/dbus-daemon. And you can probably find a usable service/socket file for systemd in the user-session-units that wiki page links to.
Thanks for the advice! Using "dbus-daemon --session &" and "dbus-launch systemd --user &" seemed to clear up the dbus-related errors (and I already picked up the dbus service/socket so that wasn't part of the problem)
However, how can I make only one session dbus-daemon initiate? I'm using .bash_profile now, although I'm sure this is far from the best way.
And is there a way to make "systemd --user" close with the session instead of fork to the background when I log out?
I really appreciate the help.
Last edited by mellowmaroon (2013-05-11 19:33:32)
dbus-launch starts dbus-daemon, so removing the explicit call to dbus-daemon would be a first step towards running a single instance. The man page suggests checking for $DBUS_SESSION_ADDRESS, and everything started with the systemd session manager will inherit that environment variable. You may still get multiple instances when you login on multiple ttys, unless you transfer the bus address somehow.
Ideally, the session instance of systemd would start the session instance of dbus-daemon (and it would do that only once). You say you have service/socket files, but apparently they are not begin started? Do you have any units depending on dbus (explicitly in the unit files)? Or does systemd print that error you showed before it gets to starting units? I must say I haven't really used sytemd --user or dbus without X myself.
To close the session manager, try `systemctl --user exit` in .bash_logout.
Ok, I completely scrapped what I put down before, as it hardly applies now.
I carefully reread what you said and realized that I hadn't enabled dbus.service as I did the other user services. The result is that everything appears to work fairly seamlessly with dbus now, so that problem is rather resolved at this point.
There is one remaining thing I would like to sort out, however. In this SuperUser question, it mentions how I would go about forking the user systemd into the background at startup. This works fairly well, but PulseAudio is undetectable when doing so. PulseAudio is detected when I start `systemd --user` manually, so I figure that will be my method for the time being. (By detected, I refer to alsamixer and pavucontrol's abilities to recognize a running instance)
Any ideas on why PulseAudio is detected only in the latter situation, rather than the former? Thanks again for the help.
Last edited by mellowmaroon (2013-05-12 19:43:33)