Bugzilla Bug 77504

This patch changes GDM's Xsession in a way a DBUS session daemon is started
when a session is started, and stopped when the session is closed.

At this moment not so many programs use the DBUS session daemon, but they're
coming.

At this point it probably isn't a good idea to start the session daemon just
because the user has dbus installed. It is something that we will need to look
into for the future though, as you said more apps will be getting dbus support.
Now that portage has the newuse feature, we could maybe add a dbus flag which
would add this option.

Actually that's what I was thinking off: create the "dbus" USE flag (I'm
working on DBUS-izing some applictions these days), and just apply the patch if
GDM is emerged with this flag set.
Of course it should dep on sys-apps/dbus too then ;-)

I'm not in favor of adding/using a dbus flag for trivialities like this, users
will want it if it's used unconditionally. If you don't have dbus it won't get
started & if you do have it, then gnome will likely use it at some point, but
right now there is nothing in the tree that uses a session daemon so thats why
I didn't add it.

When starting dbus-launch it crashes because of missing the directories
/usr/lib/dbus-1.0/service and /usr/lib/dbus-1.0/services.

Maybe the dbus ebuild should take care of this?

kai

I guess that's something wrong at your side. I got a session bus running here
all time, with some apps running on it, using latest ~x86 dbus ebuilds. System
bus (with hal on it) works great too.
I did notice the Tomboy (I guess it was that one, cant check now caus I copied
them over) service description files are installed in some faulty location (ie
not the same one as written inside session.conf).

I can confirm that Ikke's patch works great. Is it not better to have a
/etc/X11/Xsession.d directory with sessions scripts that are sourced by
/etc/X11/gdm/Xsession (or whatever). That way the dbus ebuild can put its
script in that folder so dbus starts for every new session?

What about kde users?

Re comment 6: there already exists a directory for this purpose,
/etc/X11/xinit/xinitrc.d/

I am currently using:

$ cat /etc/X11/xinit/xinitrc.d/30dbus-launch.sh
#!/bin/sh

eval `dbus-launch --sh-syntax --exit-with-session`
export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

This seems to be the accepted convention; if merged with USE=xprint xorg-x11
puts /etc/X11/xinit/xinitrc.d/92xprint-xpserverlist.sh in that directory.

Created an attachment (id=51349) [details]
/etc/X11/xinit/xinitrc.d/30dbus-launch.sh

Much simpler than patching GDM.

This can be installed by the dbus ebuild directly.

I don't seem to have a /etc/X11/xinit/xinitrc.d/ directory on my system, though
I'm using xorg-6.8.0-r4 and GDM. are you sure about what you are talking about?

@Ed: nice catch.
@Gad: I got a dir like that, with some xprint file in it. Maybe you haven't got the xprint USE flag, and isn't the directory created by the ebuild?

indeed the xprint USE flag is not on my system, I will try to create the dir
manually to see if it works...

Ikke: it works for you?
I knew of this method in other distros but thought gentoo does not work with it
because I didn't have that dir...

I just tried that... I created the dir and put the script in it - but dbus is
not started.

You may need to make it executable. I'll look to see where they're sourced
from.

Yes; gdm sources them thus:

/etc/X11/gdm/Xsession:
# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
    for i in /etc/X11/xinit/xinitrc.d/* ; do
        if [ -x "$i" ]; then
      . "$i"
        fi
    done
fi

Yes I was hasty. execute made it work - that's the best fix for it IMO. now it
should be added to the dbus ebuild...

added a session script to 0.23.2-r1 , please cheack & test.

according to spyderous xinitrc.d is a RH-ism we don't really support, so we
really shouldn't be using it.

Is there an alternative? I note that xorg-x11+xprint installs 92... to both
/etc/X11/xinit/xinitrc.d and /etc/X11/Xsession.d - should dbus do the same?

wrt comment 17, shouldn't the session script export the variables?

There is no alternative to our knowledge.

the --sh-syntax should already do the exporting, it seemed redundant to me.

--sh-syntax doesnt do the exporting itself, it only printf()'s the variables
you should export in a SH-compliant way (theres also the --csh-syntax flag). So
depending on the place where you call it, eval()'ing it can be necessary.

does this solution work with GDM only or all others login managers? does it
affect startx too?

This script does not kill my session daemon when I log out of GNOME.  Does it
do that for anyone else?

Adding myself to CC list.

Answer to comment #22:
No this script doesn't work with kdm or xdm because their various Xsession scripts doesn't source the scripts in /etc/X11/xinit/xinitrc.d/ , i.e. they miss the code snipplet from comment #15.

(In reply to comment #8)
> Re comment 6: there already exists a directory for this purpose,
> /etc/X11/xinit/xinitrc.d/
> 
> I am currently using:
> 
> $ cat /etc/X11/xinit/xinitrc.d/30dbus-launch.sh
> #!/bin/sh
> 
> eval `dbus-launch --sh-syntax --exit-with-session`
> export DBUS_SESSION_BUS_ADDRESS
> export DBUS_SESSION_BUS_PID
> 
> This seems to be the accepted convention; if merged with USE=xprint xorg-x11
> puts /etc/X11/xinit/xinitrc.d/92xprint-xpserverlist.sh in that directory.
> 

I don't have the same file, but i do have the 30-dbus file. So integrating the
two, i get: 

[code]

BeTaBoXjFS xinitrc.d # cat 30-dbus
#!/bin/bash

# launches a session dbus instance

dbuslaunch="`which dbus-launch 2>/dev/null`"

if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z
"$DBUS_SESSION_BUS_ADDRESS" ]; then

  eval `$dbuslaunch --sh-syntax --exit-with-session`

# added from http://bugs.gentoo.org/show_bug.cgi?id=77504

        export DBUS_SESSION_BUS_ADDRESS
        export DBUS_SESSION_BUS_PID
#

fi

[/code]

Hope it helps!

what is the status of this bug ?
I have the script installed (running ~x86) and the session bus is launched and
stopped the right way.

We include this script now. Gnome works fine for a while... other WMs work fine
if they process the xinitrc.d dir... I think only KDE is busted..

<genstef> ln -s /etc/X11/xinit/xinitrc.d/30-dbus /usr/kde/3.5/env/dbus.sh
<genstef> basically that is needed
<Flameeyes> genstef, i'm not sure if that is correct
<genstef> use hal && dosym /etc/X11/xinit/xinitrc.d/30-dbus
${KDEDIR}/env/dbus.sh
<genstef> why not?
* zzam has quit ("KVIrc 3.2.3 Anomalies http://www.kvirc.net/")
<Cardoe> Flameeyes: the correct thing is for KDE to process xinit stuff
<Flameeyes> Cardoe, exactly my point
<sekretarz> Cardoe: if you can check it i'd be apriciate
<Cardoe> however for now... Gentoo needs to do the hack
<Flameeyes> Cardoe, i suppose it's quite simpler to change the other thing
<Flameeyes> startkde script is the one to fix
* mabi (n=mabi@p54B878FA.dip.t-dialin.net) has joined #gentoo-dev
<Flameeyes> i think i can do that easily, but i'm not sure if carlo has put the
patches for the tarballs in CVS, so he might be the only one able to prepare
them correctly

That's the revelant part of the discussion.

Re-assigning to KDE herd since it's waiting on them now.

I have a patch that should work, waiting for genstef to test (I can't right
now), and then I'll commit it.

*** Bug 132782 has been marked as a duplicate of this bug. ***

*** Bug 138101 has been marked as a duplicate of this bug. ***

Flameyes and genstef have fixed this issue.

it is not work for launching gnome from startx (not using gdm)

solution:
add this code to /etc/X11/xinit/xinitrc

# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
    for i in /etc/X11/xinit/xinitrc.d/* ; do
        if [ -x "$i" ]; then
      . "$i"
        fi
    done
fi

It should be started by the Gnome Session script.

Someone's working with me on a more generalized solution now (see -dev list
xinit thread), it'll probably be a while before we can get where it needs to
be.