Bug 1032759

not emacs but dbus

*** This bug has been marked as a duplicate of bug 1028893 ***

(In reply to Dr. Werner Fink from comment #1)
> not emacs but dbus
> 

well emacs incorrectly checking if dbus is running :-)

(In reply to Simon Lees from comment #2)
> (In reply to Dr. Werner Fink from comment #1)
> > not emacs but dbus
> > 
> 
> well emacs incorrectly checking if dbus is running :-)

I do not agree, at least the gtk version has a lot of features based on dbus

(In reply to Dr. Werner Fink from comment #3)
> (In reply to Simon Lees from comment #2)
> > (In reply to Dr. Werner Fink from comment #1)
> > > not emacs but dbus
> > > 
> > 
> > well emacs incorrectly checking if dbus is running :-)
> 
> I do not agree, at least the gtk version has a lot of features based on dbus

Yes I agree, but emacs should be connecting to the dbus session thats already running rather then creating a new one. Due to recent changes the script is starting a new bus when there is already one running that it should connect too.

(In reply to Simon Lees from comment #4)
> (In reply to Dr. Werner Fink from comment #3)
> > (In reply to Simon Lees from comment #2)
> > > (In reply to Dr. Werner Fink from comment #1)
> > > > not emacs but dbus
> > > > 
> > > 
> > > well emacs incorrectly checking if dbus is running :-)
> > 
> > I do not agree, at least the gtk version has a lot of features based on dbus
> 
> Yes I agree, but emacs should be connecting to the dbus session thats
> already running rather then creating a new one. Due to recent changes the
> script is starting a new bus when there is already one running that it
> should connect too.

Hmmm ... Is there no DBUS_SESSION_BUS_ADDRESS variable anymore? As this should work with both Leap and Tumbleweed how to perform here?

(In reply to Dr. Werner Fink from comment #5)
> (In reply to Simon Lees from comment #4)
> > (In reply to Dr. Werner Fink from comment #3)
> > > (In reply to Simon Lees from comment #2)
> > > > (In reply to Dr. Werner Fink from comment #1)
> > > > > not emacs but dbus
> > > > > 
> > > > 
> > > > well emacs incorrectly checking if dbus is running :-)
> > > 
> > > I do not agree, at least the gtk version has a lot of features based on dbus
> > 
> > Yes I agree, but emacs should be connecting to the dbus session thats
> > already running rather then creating a new one. Due to recent changes the
> > script is starting a new bus when there is already one running that it
> > should connect too.
> 
> Hmmm ... Is there no DBUS_SESSION_BUS_ADDRESS variable anymore? As this
> should work with both Leap and Tumbleweed how to perform here?

See the other bug report, I can probably have a shot at making you a SR tomorrow, It doesn't seem like i'll be that busy.

(In reply to Simon Lees from comment #6)

> 
> See the other bug report, I can probably have a shot at making you a SR
> tomorrow, It doesn't seem like i'll be that busy.

--- emacs.sh (revision 129)
+++ emacs.sh (revision 227)
@@ -78,7 +78,12 @@
            unset DBUS_SESSION_BUS_ADDRESS
            break
        done
-       test -n "$dpid" || unset DBUS_SESSION_BUS_ADDRESS
+       if test -z "$dpid" ; then
+           case ":$DBUS_SESSION_BUS_ADDRESS" in
+           *:path=/run/user/${UID}/bus*) ;;
+           *)  unset DBUS_SESSION_BUS_ADDRESS
+           esac
+       fi
     fi
     # Find a valid dbus-daemon if active
     if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
@@ -90,6 +95,10 @@
            DBUS_SESSION_BUS_ADDRESS=${dadd#*=}
            export DBUS_SESSION_BUS_ADDRESS
        done
+       if test -z "$DBUS_SESSION_BUS_ADDRESS" -a -S /run/user/${UID}/bus ; then
+           DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${UID}/bus
+           export DBUS_SESSION_BUS_ADDRESS
+       fi
     fi

This is an autogenerated message for OBS integration:
This bug (1032759) was mentioned in
https://build.opensuse.org/request/show/491041 Factory / emacs

(In reply to Dr. Werner Fink from comment #7)
> (In reply to Simon Lees from comment #6)
> 
> > 
> > See the other bug report, I can probably have a shot at making you a SR
> > tomorrow, It doesn't seem like i'll be that busy.
> 
> --- emacs.sh (revision 129)
> +++ emacs.sh (revision 227)
> @@ -78,7 +78,12 @@
>             unset DBUS_SESSION_BUS_ADDRESS
>             break
>         done
> -       test -n "$dpid" || unset DBUS_SESSION_BUS_ADDRESS
> +       if test -z "$dpid" ; then
> +           case ":$DBUS_SESSION_BUS_ADDRESS" in
> +           *:path=/run/user/${UID}/bus*) ;;
> +           *)  unset DBUS_SESSION_BUS_ADDRESS
> +           esac
> +       fi
>      fi
>      # Find a valid dbus-daemon if active
>      if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
> @@ -90,6 +95,10 @@
>             DBUS_SESSION_BUS_ADDRESS=${dadd#*=}
>             export DBUS_SESSION_BUS_ADDRESS
>         done
> +       if test -z "$DBUS_SESSION_BUS_ADDRESS" -a -S /run/user/${UID}/bus ;
> then
> +           DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${UID}/bus
> +           export DBUS_SESSION_BUS_ADDRESS
> +       fi
>      fi

Sorry for wasting your time, i've only just got to confirming the following, dbus is socket activated when required so you shouldn't need to launch it. To test this you can ssh in then run dbus monitor which is enough to start the dbus session.

(In reply to Simon Lees from comment #9)
> Sorry for wasting your time, i've only just got to confirming the following,
> dbus is socket activated when required so you shouldn't need to launch it.
> To test this you can ssh in then run dbus monitor which is enough to start
> the dbus session.


Back your pardon ... the scripts seems to work, that is that no messages are
shown but at the very first try the emacs(-gtk) crashed with abort away as
there was no dbus activated.  I'll investigate what does cause this .... 
if the script its self does trigger a launch or if emacs its self cause via
the socket activation but GTK does not like this.  I gues that the last point 
is true as I see

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
werner    6734  0.0  0.1  69044  7624 ?        Ss   08:24   0:00 /usr/lib/systemd/systemd --user
werner    6746  0.0  0.0 107420  2416 ?        S    08:24   0:00 (sd-pam)
werner    6860  0.0  0.1 116956  4208 ?        S    08:24   0:00 sshd: werner@pts/3
werner    6922  0.0  0.0  11264  3644 pts/3    Ss   08:24   0:00 -tcsh
werner   11827  1.0  1.5 435040 63360 pts/3    Sl   08:33   0:01 /usr/bin/emacs
werner   13891  0.0  0.0  38212  2008 pts/3    R+   08:36   0:00 ps xu
werner   20635  0.0  0.1  44324  4336 ?        Ss   08:30   0:00 /bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
werner   20637  0.0  0.1 280908  6488 ?        Ssl  08:30   0:00 /usr/lib/gvfs/gvfsd
werner   20860  0.0  0.1  66776  5840 ?        S    08:30   0:00 /usr/lib/GConf/2/gconfd-2

Hmmm ... the abort is not reproducable by terminating dbus, gvfsd, and gconfd-2 ... means that this might be a race or a virgin aka a very first ssh/slogin is required (after a reboot)

Nevertheless, the script does not launch a dbus (no dbus-run-session and no dbus-launch)

This is an autogenerated message for OBS integration:
This bug (1032759) was mentioned in
https://build.opensuse.org/request/show/491205 Factory / emacs

This is an autogenerated message for OBS integration:
This bug (1032759) was mentioned in
https://build.opensuse.org/request/show/492450 Factory / emacs

SUSE-RU-2017:1784-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1032759,1035645,1044093
CVE References: 
Sources used:
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    emacs-24.3-24.1
SUSE Linux Enterprise Server 12-SP2 (src):    emacs-24.3-24.1
SUSE Linux Enterprise Desktop 12-SP2 (src):    emacs-24.3-24.1

openSUSE-RU-2017:1855-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1032759,1035645,1044093
CVE References: 
Sources used:
openSUSE Leap 42.2 (src):    emacs-24.3-24.3.1