I get the same problem using bash, so I would assume the shell is innocent. I start dbus-launch right from within .bash_profile together with xinit (i.e. the traditional way):

if [ "`tty`" = "/dev/tty1" ]; then
    startx="xinit -- :4 -br -quiet"
    test -x /usr/bin/dbus-launch && \
        startx="/usr/bin/dbus-launch --exit-with-session $startx"
    $startx >& .xinitrc.log
fi

Distro is Debian sid (amd64).

How comes that this bug report staid in status "NEW" for almost 2 years? Could nobody from the core developers reproduce this problem? 

Please mail if I can help.

I don't think this happens for most people. It looks like you're starting dbus before X, so dbus can't connect to X, which makes --exit-with-session not able to exit when the X server does. Most distributions are not configured that way.

I am just starting dbus-launcher with "--exit-with-session xinit ...". I do not see what is happening inside, but dbus-launcher seems to start dbus-daemon, and then it starts xinit. It could terminate dbus-daemon when xinit terminates (watching both via wait(2) or sigaction(2) as usual), and then exit with xinit's exit value.

Actually I don't see any reason why Dbus should work with XWindow only. Wouldn't you agree that Dbus could be used for all kinds of applications?

--exit-with-session optionally connects to the X server, so it can exit when the X server does. This is the most reliable way to do things. But if you start --exit-with-session *before* you start X, then it can't connect to the X server.


dbus-launch could terminate when the launched child does, but it doesn't do that now and isn't designed/documented to do that now, iirc. It probably is not a compatible change so would be a new feature like --exit-with-launched-child

I doubt that Xwindow's IPC is more reliable than a SIGCHLD sent by the kernel. 

AFAICS there are at least 3 problems with --exit-with-session:

The XWindow server is supposed to do a reset if the last client connection goes away. If dbus-launch keeps that last connection active (as the man page seems to indicate), then X never does a reset.

Even though the XWindow server might be running, the authentication scheme between Xserver and the clients might not be setup yet when dbus-launch comes into the game.

Since --exit-with-session polls stdin it keeps your terminal busy. This has the "nice" effect that if you run the Xwindow client script as a background process, dbus-launch eats up every second char you type on the terminal. (At least this annoyance is reliable.)

Talking about a new command line option: I could live with that.

Bug is still here, and really annoying in my case.

(In reply to comment #5) 
> Since --exit-with-session polls stdin it keeps your terminal busy. This has the
> "nice" effect that if you run the Xwindow client script as a background
> process, dbus-launch eats up every second char you type on the terminal. (At
> least this annoyance is reliable.)

(running dbus-1.41 on gentoo)

i think this is my confirmation that this is the bug i also care about. trying to work with dbus with no X seems to be a bit of a hassle.

if i do "dbus-launch --exit-with-session" over ssh (because i would like dbus-daemon to quit when i log out or get disconnected), i get the nifty character eating phenomenon for a bit, and after a timeout, dbus-launch just gives up on trying to reach X (i think) and doesn't give me a dbus-daemon at all.

if i do the regular "eval `dbus-launch --sh-syntax`" dance, i get a properly working dbus-daemon, except none of "dbus-daemon --fork --session" instances will ever quit without me manually killing them. they stay running indefinitely irregardless of me logging out of the ssh bash session. is there a limit to how many of these idling dbus-daemon's it is possible to pile up?

on top of this, there seems to be no well known way to use a user's pre-existing dbus-daemon, conclusion reached after a few hours of googling. i for one am not able to figure out when exactly ~/.dbus/session-bus directory gets a session id in it and whether this id is reliable for exporting as $DBUS_SESSION_BUS_ADDRESS for another session or how long it'll last. trying to find processes that *might* be involved in a previous dbus session with /proc/PID/environ just doesn't sound right to me.

(granted i have not peeked dbus source yet)

this effectively leaves me with no properly working automated way to automatically launch dbus with no X to provide for things like gnome-keyring-daemon, subversion + whatever else.

please let me know if i'm missing something substantial here.

I think there are (at least) two related bugs here:

(In reply to comment #4)
> dbus-launch could terminate when the launched child does, but it doesn't do
> that now and isn't designed/documented to do that now, iirc. It probably is not
> a compatible change so would be a new feature like --exit-with-launched-child

and

(In reply to comment #5)
> Since --exit-with-session polls stdin it keeps your terminal busy. This has the
> "nice" effect that if you run the Xwindow client script as a background
> process, dbus-launch eats up every second char you type on the terminal.

http://bugs.debian.org/453755 is the same thing as this. xdm and gdm avoid this because they redirect stdin from /dev/null, but slim doesn't; I've been able to reproduce this in a virtual machine with slim installed.

I'm sure I've seen another bug report here in which someone mentioned that --exit-with-session's stdin polling didn't really work either, and suggested removing it, but I can't find it right now.

Bug #19997 is vaguely related.

Replying to the original bug:

(In reply to comment #0)
> It's launched from xinitrc(-common) as follows:
> 
> [ -x /usr/bin/dbus-launch -a -z "$DBUS_SESSION_BUS_ADDRESS" ] &&
> DBUS_LAUNCH="/usr/bin/dbus-launch --exit-with-session"

That just sets a variable. How is that variable (DBUS_LAUNCH) used?

Does this still happen with current Fedora packaging of current D-Bus?

This may have been fixed by this commit:

> commit 7d409700c354e7a35989053ba037750d320a308a
> Author: John (J5) Palmieri <johnp@redhat.com>
> Date:   2008-02-21 12:02:58 -0500
> 
>     fixes dbus-launch so the bus goes away when X does (Red Hat Bug #430412)

(In reply to comment #1)
> I start dbus-launch right from within .bash_profile together with xinit
> (i.e. the traditional way):
> 
> if [ "`tty`" = "/dev/tty1" ]; then
>     startx="xinit -- :4 -br -quiet"
>     test -x /usr/bin/dbus-launch && \
>         startx="/usr/bin/dbus-launch --exit-with-session $startx"
>     $startx >& .xinitrc.log
> fi

This isn't right. To make dbus-launch exit reliably with your X session (i.e. make --exit-with-session work), you should start it from within X, so instead of:

    dbus-launch --exit-with-session xinit -- :4 -br -quiet

you should wrap dbus-launch around your initial X client, something like:

    xinit dbus-launch --exit-with-session ~/.xinitrc -- :4 -br -quiet

or run dbus-launch from within your .xinitrc:

    #!/bin/sh
    # .xinitrc
    dbus-launch --exit-with-session openbox

or just let the /etc/X11/Xsession machinery that Debian provides do its job - if you don't have a .xinitrc, Debian's default sources /etc/X11/Xsession, which runs things from /etc/X11/Xsession.d (including dbus-launch), then runs your ~/.xsession. Renaming your ~/.xinitrc to ~/.xsession will probably do the right thing.

(In reply to comment #4)
> dbus-launch could terminate when the launched child does, but it doesn't do
> that now and isn't designed/documented to do that now, iirc.

Its code structure actually prevents it from doing that in a reliable way (it isn't the parent of the launched child, so it won't get SIGCHLD; and you want the launched child to be at the top of the process hierarchy so job control works).

Having something that *does* terminate with the launched child is basically a feature request, which I've cloned to <https://bugs.freedesktop.org/show_bug.cgi?id=39196>.

(In reply to comment #5)
> The XWindow server is supposed to do a reset if the last client connection goes
> away. If dbus-launch keeps that last connection active (as the man page seems
> to indicate), then X never does a reset.

dbus-launch is designed to be used with an xinit-like arrangement, which terminates when the exec'd child process (a window manager or gnome-session or something) terminates.

> Even though the XWindow server might be running, the authentication scheme
> between Xserver and the clients might not be setup yet when dbus-launch comes
> into the game.

When used with X, dbus-launch is not designed to be run before X is functional.

> Since --exit-with-session polls stdin it keeps your terminal busy.

This is <https://bugs.freedesktop.org/show_bug.cgi?id=39197>

(In reply to comment #7)
> if i do "dbus-launch --exit-with-session" over ssh (because i would like
> dbus-daemon to quit when i log out or get disconnected)

You want "exec dbus-run-session bash" or some such, once my patches from Bug #39196 (adding dbus-run-session) have been merged. There doesn't seem to be any reliable way to detect logout/disconnection without either being in the foreground (like dbus-run-session would) or polling the terminal.

> if i do the regular "eval `dbus-launch --sh-syntax`" dance, i get a properly
> working dbus-daemon, except none of "dbus-daemon --fork --session" instances
> will ever quit without me manually killing them.

Yes, this is working as intended. You're running them in a way that isn't scoped to a particular session (although the only reliable indication of a session is X, which you don't have; the unwanted stdin polling is a side-effect of a mostly-failed attempt to detect tty session lifetime). So, they can only assume that the session lasts forever, until you indicate otherwise (by killing the dbus-daemon).

> on top of this, there seems to be no well known way to use a user's
> pre-existing dbus-daemon

Your new shell is not part of the previous session, so, no, there isn't.

It looks as though this bug as initially filed (by Jan Houtsma) is a bug in either D-Bus from 2007, or Fedora's packaging of it. I'll close it if this can be resolved.

Subsequent comments from Harri and from Leho Kraav appear to be either separate bugs, missing features, or using dbus-launch incorrectly, which would be addressed by either fixing Bug #39196, fixing Bug #39197, or starting the X session differently. For those, please follow up on Bug #39196 or Bug #39197, as appropriate.

(In reply to comment #13)
> It looks as though this bug as initially filed (by Jan Houtsma) is a bug in
> either D-Bus from 2007, or Fedora's packaging of it. I'll close it if this can
> be resolved.

Jan, is this bug still present? If not, please say so so we can close it.

I think this problem still does exist (or at least we hit it quite often running Ubuntu 12.04 (so not the latest), dbus 1.4.18, kernel 3.2.0-52).

(In reply to comment #14)
> (In reply to comment #13)
> > It looks as though this bug as initially filed (by Jan Houtsma) is a bug in
> > either D-Bus from 2007, or Fedora's packaging of it. I'll close it if this can
> > be resolved.
> 
> Jan, is this bug still present? If not, please say so so we can close it.

I can not comment on this, because i don't run this server anymore. 

Regards, Jan

(In reply to comment #15)
> I think this problem still does exist (or at least we hit it quite often
> running Ubuntu 12.04 (so not the latest), dbus 1.4.18, kernel 3.2.0-52).

Please open a separate bug for this with:

- steps that reproduce the bug
  (ideally starting with "install Ubuntu 12.04 (desktop) in a virtual
  machine" to rule out misconfiguration)
- what you expected to happen
- what happened
- details of how your distribution starts dbus

I don't think trying to track this together with a 7.5 year old bug that happens to have similar symptoms is really going to benefit anyone.

(In reply to comment #16)
> I can not comment on this, because i don't run this server anymore. 

Then we can never know whether this bug has been fixed, so I don't think there's a great deal of value in having it in the bug-list. Resolving WORKSFORME; please open a new bug with details (like those requested in Comment #17) if the same symptoms are reproducible in a modern version of dbus.