Your message dated Mon, 15 Oct 2012 10:48:06 +0100 with message-id <[email protected]> and subject line Re: Bug#690530: dbus: Unable to launch DBus services without X11 running has caused the Debian Bug report #690530, regarding dbus: Unable to launch DBus services without X11 running to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 690530: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690530 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dbus Version: 1.6.8-1 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? I ran, e.g., aplay from the console (no X11 running) with PulseAudio installed and configured. * What was the outcome of this action? Oct 15 18:49:11 jdc pulseaudio[9803]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 * What outcome did you expect instead? A DBus daemon should have been launched and PulseAudio started within the user's session, which was all working perfectly until recently. Note that Alsa is configured to run PulseAudio, if the latter is installed, so the resulting symptom in that case is no audio. Obviously, however, this is a general DBus issue - PulseAudio is only an example of how it bites. *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dbus depends on: ii adduser 3.113+nmu3 ii libc6 2.13-35 ii libdbus-1-3 1.6.8-1 ii libexpat1 2.1.0-1 ii libselinux1 2.1.9-5 ii libsystemd-login0 44-4 ii lsb-base 4.1+Debian7 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 1.6.8-1 -- no debconf information
--- End Message ---
--- Begin Message ---On 15/10/12 09:35, Jason White wrote: > Oct 15 18:49:11 jdc pulseaudio[9803]: [pulseaudio] main.c: Unable to contact > D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a > dbus-daemon without a $DISPLAY for X11 This is not considered to be a bug. Auto-launching D-Bus sessions when not under X11 would result in one new D-Bus session per application that tried to use it, unable to communicate with other user-facing applications that do not share that session; those sessions would also never exit, leaving unused dbus-daemon and dbus-launch processes building up indefinitely (until the next reboot). That's clearly not useful or desirable, but in the absence of a clear and machine-detectable definition of "session" we can't really improve on it. (Under X11, the lifetime of the X server acts as the definition of the session, so autolaunching can work and is useful.) Applications that can usefully be run either with or without a D-Bus session, such as pulseaudio, should treat errors in connecting to the session bus as non-fatal, and continue to have the rest of their functionality. I believe PA already does this, in fact; that message in your syslog just tells you that the D-Bus part of its functionality will not be active. If you do need to start a D-Bus session while not under X11, you can run dbus-launch as documented in the dbus-launch(1) man page, something like this: if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then eval `dbus-launch --sh-syntax` echo "D-Bus per-session daemon address is:" echo "$DBUS_SESSION_BUS_ADDRESS" fi in which case you're responsible for getting the DBUS_SESSION_BUS_ADDRESS environment variable to all the processes that should share the session, and managing the lifetime of the session (i.e. killing the session's dbus-daemon when appropriate). I have sent patches upstream to add a dbus-run-session tool that runs a session for as long as its child process is running and then terminates it (similar semantics to schroot), but they haven't been merged yet. Older versions of dbus-launch tried to monitor the lifetime of text login sessions on virtual consoles, but the way they did that would consume every second character of input (Debian bug #453755) and it isn't clear whether it actually ended the session on logout either. This was fixed by several changes between squeeze and wheezy. Regards, S
--- End Message ---
