gnome-shell-extension-gsconnect 🚀 - GSConnect doesn't support dbus-broker

I'm afraid there's not much here indicating why the service isn't starting over DBus, could you enabled _Debug Mode_ in the About page of preferences and see if that has any useful output?

andyholmes on 6 Apr 2018

I have a very similar error when I try to open the settings dialog:

`Gio.IOErrorEnum: Fehler beim Aufruf von StartServiceByName für org.gnome.Shell.Extensions.GSConnect: Zeitüberschreitung wurde erreicht

Stack trace:
ProxyBase<._init@/usr/share/gnome-shell/extensions/[email protected]/client.js:33:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_parent@resource:///org/gnome/gjs/modules/_legacy.js:39:12
Daemon<._init@/usr/share/gnome-shell/extensions/[email protected]/client.js:695:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
PrefsWidget<._init@/usr/share/gnome-shell/extensions/[email protected]/prefs.js:100:23
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
buildPrefsWidget@/usr/share/gnome-shell/extensions/[email protected]/prefs.js:215:23
_selectExtension@resource:///org/gnome/shell/extensionPrefs/main.js:91:22
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_onCommandLine@resource:///org/gnome/shell/extensionPrefs/main.js:243:17
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
main@resource:///org/gnome/shell/extensionPrefs/main.js:397:5
@

:1:43`

Simply reloading the shell after installing the extension also fails with:
gnome-shell[1711]: Extension "[email protected]" had error: TypeError: systemIndicator is undefined sh[22340]: /usr/share/gnome-shell/extensions/[email protected]/service/daemon.js": -c: Zeile 0: Dateiende beim Suchen nach"' erreicht.
sh[22340]: /usr/share/gnome-shell/extensions/[email protected]/service/daemon.js": -c: Zeile 1: Syntax Fehler: Unerwartetes Dateiende.
gnome-shell[22078]: Extension "[email protected]" had error: Gio.IOErrorEnum: Fehler beim Aufruf von StartServiceByName für org.gnome.Shell.Extensions.GSConnect: Zeitüberschreitung wurde erreicht
`

Taijian on 15 Apr 2018

I still can't reproduce this myself, and the error output posted doesn't say much about what is happening here. Can you confirm that:

you are using the latest version (v11)
your version of gjs >= 1.48, gnome-shell >= 3.24
the file /usr/bin/env is present on your system

The problem here seems to be during execution of daemon.js via the .desktop file, which is how the service is started over DBus, but I have no clues as to why it is not. If you can't open the preferences window to enable debug mode this will be more difficult to diagnose, but you may get more information by running:

journalctl -f -o cat /usr/bin/gjs

and

journalctl -f -o cat /usr/bin/gnome-shell

In terminal windows before trying to launch the service.

andyholmes on 15 Apr 2018

Happens to me, too.

I’m using the latest release from the GitHub releases page. My GJS is 1.52.2. GNOME Shell is 3.28.1 (from the Fedora 28 repo).

The journalctl output doesn’t seem to be of help, as it contains nothing related to GSConnect (in fact, gjs log is completely empty.)

gergelypolonkai on 24 Apr 2018

Sorry, I should have been a bit clearer. You'll have to get the journalctl commands running in a terminal, then try to start the service again. The easiest way to start the service starting is to close and open the preferences window or restarting Gnome Shell which should trigger the DBus activation. If the service hasn't stopped you'll probably have to kill it manually before doing that:

kill -9 $(ps aux | grep '[d]aemon.js' | awk '{print $2}')

There's certain to be less output than there would be if 'debug mode' were enabled, but if the preferences window won't open that's difficult to enable because the GSchema is relocatable so the settings aren't modifiable by normal, external means.

I've recently update to Gnome 3.28 on Ubuntu, with a clean install of GSConnect but I still can't reproduce this particular problem. If the daemon can be started directly, but just not over DBus then there must be something different between distribution's handling of DBus activation, but it's unclear what that is.

andyholmes on 24 Apr 2018

That’s exactly what I did:

make sure daemon.js is not running
open a terminal with two tabs, running the two journalctl commands you suggested
restart GNOME Shell

And the journalctl log was pretty much empty (at least the relevant parts); it seems the extension doesn’t even try to start it.

However, when I try to open the settings panel, I get this error:

```
Gio.IOErrorEnum: Error calling StartServiceByName for org.gnome.Shell.Extensions.GSConnect: Timeout was reached

Stack trace:
ProxyBase<._init@/home/polesz/.local/share/gnome-shell/extensions/[email protected]/client.js:33:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_parent@resource:///org/gnome/gjs/modules/_legacy.js:39:12
Daemon<._init@/home/polesz/.local/share/gnome-shell/extensions/[email protected]/client.js:695:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
PrefsWidget<._init@/home/polesz/.local/share/gnome-shell/extensions/[email protected]/prefs.js:100:23
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
buildPrefsWidget@/home/polesz/.local/share/gnome-shell/extensions/[email protected]/prefs.js:215:23
_selectExtension@resource:///org/gnome/shell/extensionPrefs/main.js:91:22
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_onCommandLine@resource:///org/gnome/shell/extensionPrefs/main.js:243:17
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
main@resource:///org/gnome/shell/extensionPrefs/main.js:397:5
@

:1:43
```

gergelypolonkai on 26 Apr 2018

Oh okay, in that case this must be an error with the DBus activation. Hopefully user DBus services have not been disallowed or disabled in these distributions; could you check that the DBus service file has been installed and is setup to the right path?

$ cat ~/.local/share/dbus-1/services/org.gnome.Shell.Extensions.GSConnect.service 
[D-BUS Service]
Name=org.gnome.Shell.Extensions.GSConnect
Exec=/bin/sh -c "gjs /home/andrew/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js"

If so, does the daemon start correctly if you run the command in the Exec line above?

andyholmes on 26 Apr 2018

Here's what happens on my system:

[gunnar@alien-arch ~]$ /bin/sh -c "gjs /usr/share/gnome-shell/extensions/[email protected]/service/daemon.js"

(org.gnome.Shell.Extensions.GSConnect:9325): Gjs-WARNING **: 23:42:09.781: JS ERROR: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.MatchRuleInvalid: Invalid match rule
Daemon<._initNotificationListener@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:501:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Daemon<.vfunc_startup@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:754:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Daemon<._init@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:213:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:892:2

^C
[gunnar@alien-arch ~]$

I CTRL+C at some point because the system just freezes at that point and does nothing.

Taijian on 26 Apr 2018

Hmm, I'm somewhat surprised that could stall the daemon if the match rule failed, and I'm not sure what could have changed to make the match rule invalid. It's really the most basic of match rules possible.

Could you tell me what version of DBus you have installed?

andyholmes on 27 Apr 2018

[gunnar@alien-arch ~]$ Qs dbus
local/dbus 1.12.6-1
    Freedesktop.org message bus system
local/dbus-broker 12-1
    Linux D-Bus Message Broker
local/dbus-glib 0.110-1
    GLib bindings for DBUS
local/kdbusaddons 5.45.0-1 (kf5)
    Addons to QtDBus
local/lib32-dbus 1.12.6-1
    Freedesktop.org message bus system (32-bit)
local/lib32-libdbusmenu-glib 16.04.0-2
    Library for passing menus over DBus (32-bit)
local/lib32-libdbusmenu-gtk2 16.04.0-2
    Library for passing menus over DBus (32-bit) (GTK+ 2 library)
local/libdbusmenu-glib 16.04.0-2
    Library for passing menus over DBus
local/libdbusmenu-gtk2 16.04.0-2
    Library for passing menus over DBus (GTK+ 2 library)
local/libdbusmenu-gtk3 16.04.0-2
    Library for passing menus over DBus (GTK+ 3 library)
local/libdbusmenu-qt5 0.9.3+16.04.20160218-1
    A library that provides a Qt implementation of the DBusMenu spec
local/python-dbus 1.2.6-1
    Python 3.6 bindings for DBUS
local/python-dbus-common 1.2.6-1
    Common dbus-python files shared between python-dbus and python2-dbus
local/python2-dbus 1.2.6-1
    Python 2.7 bindings for DBUS
[gunnar@alien-arch ~]$

Taijian on 27 Apr 2018

Hmm, I think there's a chance eavesdropping DBus methods has been restricted on your distribution. This would complicate things somewhat since it means opening a new DBus connection for monitoring, which itself may be restricted; are you very familiar with Arch in terms of security and permissions?

I'll have to see if the same is true for the other users on this thread.

andyholmes on 27 Apr 2018

Well, there is this wrt eavesdropping:

[gunnar@alien-arch ~]$ systemctl --user status dbus-broker
● dbus-broker.service - D-Bus User Message Bus
   Loaded: loaded (/usr/lib/systemd/user/dbus-broker.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-04-26 23:33:44 CEST; 35min ago
     Docs: man:dbus-broker-launch(1)
 Main PID: 1261 (dbus-broker-lau)
   CGroup: /user.slice/user-1026.slice/[email protected]/dbus-broker.service
           ├─1261 /usr/bin/dbus-broker-launch --scope user --verbose
           └─1262 dbus-broker -v --log 4 --controller 8

Apr 26 23:33:44 alien-arch systemd[1164]: Starting D-Bus User Message Bus...
Apr 26 23:33:44 alien-arch dbus-broker-launch[1261]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Apr 26 23:33:44 alien-arch dbus-broker-launch[1261]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Apr 26 23:33:44 alien-arch systemd[1164]: Started D-Bus User Message Bus.

Other than that, I am not really that much an expert in terms of security and stuff, but if you tell me what it is that you need to know exactly, I could try to check.

Taijian on 27 Apr 2018

Ah, I think I see what's happened.

It's (relatively) newer, but there is a new method preferred for listening in on a DBus service; in this case we (KDE Connect and GSConnect) listen for notifications sent to org.freedesktop.Notifications so we can forward them. The old way was just to just call the method AddMatch() with the eavesdrop=true.

Although deprecated this should still be supported, but I see now you are also running dbus-broker which is some new-fangled Fedora implementation (or something, I'm kind of fuzzy on it). This might default to blocking/not-implementing deprecated features. That would explain why this is affecting Arch users and Fedora users, but not Ubuntu users (like me).

In that case, I'll probably have to actually deal with this instead of just redirecting responsibility elsewhere.

EDIT

This was just confirmed for me in #gnome-hackers :(

andyholmes on 27 Apr 2018

Here's a super rough draft of a fix. If you could tell me if this at least gets GSConnect starting, and if possible forwards notifications correctly, it would help me out a lot since I don't have dbus-broker:

[email protected]

There's instructions for installing from zip here. You could send a test notification using notify-send like so:

$ notify-send -a NotificationTest SUMMARY BODY

andyholmes on 27 Apr 2018

OK, there is progress!

Using your notify-send snippet I got a pop-up telling me SUMMARY BODY, so that part works. Gnome-Tweaks still says that the extension cannot be activated and trying to open the settings dialogue still triggers the same error message after a lengthy pause, but you seem to be on the right track!

I'm happy to test more stuff, if you need me to!

Taijian on 27 Apr 2018

If you run the daemon from the terminal like before (making sure it's not still running) do you get anymore error messages that might be helpful?

andyholmes on 27 Apr 2018

OK, so this is weird (at least to me). I was now able to get the extension to start from the cli without any error messages. I then restarted gnome-shell, opened Tweak-Tool and now I was able to open the settings dialogue and add my phone and adjust settings.

When I then terminated the instance running from cli and restarted the shell again, it would again error out. So starting from cli=good, automatic loading with gnome-shell=bad. Does that help in any way?

Taijian on 27 Apr 2018

I’m on Fedora 28, and also use DBus-broker.

Your “super rough draft of a fix” makes it possible to run the daemon up from the command line. The extension also fires up fine, and I could also pair with my phone (although the Settings panel didn’t show my device until I closed and re-opened it, but I guess that’s a separate bug).

gergelypolonkai on 27 Apr 2018

Taijian: ...able to get the extension to start from the cli without any error messages...now I was able to open the settings dialogue and add my phone and adjust settings.

gergelypolonkai: ...possible to run the daemon up from the command line...extension also fires up fine

That's good news, that likely means the dbus-broker issue is fixed at least. That's good because as I understand it dbus-broker is likely to be a part of everyone's distro by next release cycle anyways.

Taijian: So starting from cli=good, automatic loading with gnome-shell=bad. Does that help in any way?

That probably means we were dealing with two separate issues from the beginning, but it does help. This would confirm my suspicion that the problem has to do with DBus activation, which is a method for starting a service on-demand when one of it's functions is called (Gnome Shell search also does this, for example).

Unfortunately, it probably means enabling the extension's debug mode won't help. The best way to get an error is either through journalctl or Gnome Logs (just a front-end for jounralctl). If you use journalctl I would do it like this:

journalctl -f -o cat

Once that's running, scroll a single line up in gnome-terminal to hold your spot and prevent autoscrolling. Then restart Gnome Shell and once it's done failing, slowly scroll down through the output until you see something related to org.gnome.Shell.Extensions.GSConnect. This might be easier for you in Gnome Logs, but it tends to combine multiple errors into one widget which sometimes makes it's harder to find something if you're not sure exactly what you're looking for.

gergelypolonkai: the Settings panel didn’t show my device until I closed and re-opened it

This happens to me too actually. When the Settings window is first opened, it sends out a single UDP broadcast (hitting Refresh does the same), but for some reason it seems to always take two broadcasts for a device to respond. I've always attributed it up to UDP not guaranteeing broadcasts are received, but who knows.

andyholmes on 27 Apr 2018

OK, here goes what journalctl has to say wrt gsconnect:

[[email protected]]: initializing extension
[[email protected]]: enabling extension
Created slice dbus\x2d:1.2\x2dorg.gnome.Shell.Extensions.GSConnect.slice.
Started dbus-:[email protected].
/home/gunnar/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js": -c: Zeile 0: Dateiende beim Suchen nach `"' erreicht. (DE2EN: line0: EOF reached searching for `"')
/home/gunnar/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js": -c: Zeile 1: Syntax Fehler: Unerwartetes Dateiende. (DE2EN: Syntax Error: unexpected EOF)
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
Extension "[email protected]" had error: Gio.IOErrorEnum: Fehler beim Aufruf von StartServiceByName für org.gnome.Shell.Extensions.GSConnect: Zeitüberschreitung wurde erreicht (DE2EN: Error calling ...: timed out)

Taijian on 27 Apr 2018

Hmm, could you give me the output of

cat ~/.local/share/dbus-1/services/org.gnome.Shell.Extensions.GSConnect.service

Just to be sure that says what it should say?

andyholmes on 27 Apr 2018

[gunnar@alien-arch ~]$ cat ~/.local/share/dbus-1/services/org.gnome.Shell.Extensions.GSConnect.service
[D-BUS Service]
Name=org.gnome.Shell.Extensions.GSConnect
Exec=/bin/sh -c "gjs /home/gunnar/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js"

Taijian on 27 Apr 2018

Hrm, my best guess at this point is that this is a quoting problem (eg. I should be using ' not "), although that would be bizarre... Could you try this zip for me?

[email protected]

After installing and restarting Gnome Shell, the file should be the same except with single quotes:

Exec= /bin/sh -c 'gjs ...'

andyholmes on 27 Apr 2018

OK, I simply edited the file by hand and restarted the shell. journalctl now no longer gives me the EOF error, but still this:

[[email protected]]: initializing extension
[[email protected]]: enabling extension
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
g_variant_get_va: assertion 'value != NULL' failed
g_variant_unref: assertion 'value != NULL' failed
Extension "[email protected]" had error: Gio.IOErrorEnum: Fehler beim Aufruf von StartServiceByName für org.gnome.Shell.Extensions.GSConnect: Zeitüberschreitung wurde erreicht

Taijian on 27 Apr 2018

Gah. Okay, well I'll keep digging, but I'll have to come back to it tomorrow since it's quite late. Thanks for working through this with me, I'm sure we'll get it eventually!

andyholmes on 27 Apr 2018

👍1

Try this for for me, change the .service file to this:

[D-BUS Service]
Name=org.gnome.Shell.Extensions.GSConnect
Exec=/home/gunnar/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js

And make the script executable:

chmod a+x /home/gunnar/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js

If this avoids problems caused by using sh -c, then maybe that's the solution here.

andyholmes on 27 Apr 2018

OK, so the problem with this is that whenever I restart the shell, the .service file gets overwritten again...

But even so, there is no change in the error messages, but I have no idea if that happens before the file gets overwritten, or simultaneously, or whatever :(

Taijian on 27 Apr 2018

Ah, that makes sense. Okay try installing this zip then:

[email protected]

andyholmes on 27 Apr 2018

Nope, still not change, just a bunch of value != NULL error messages...

Taijian on 27 Apr 2018

Okay, I'm thinking now that this is another dbus-broker issue which says this with regard to DBus activation:

With dbus-broker, direct activation is no longer supported, rather all activation requests are forwarded to systemd.

This means I need to make a systemd service file in addition to the DBus service file; Bear with me, I'm just trying to sort through this now.

andyholmes on 27 Apr 2018

Okay, I think I have this mostly figured out now. The only thing holding me back from pushing to master is that when/if the extension directory is removed there is hard hang of 30 seconds or more as the (still loaded) shell extension tries to restart the daemon.

What starts this off, is that anytime a running GSConnect daemon notices daemon.js has been updated it exits; conversely, anytime the shell extension notices the daemon has exited it restarts it. This allows the extension to gracefully handle updates automatically.

This used to not be a problem as the daemon would just instantly fail to start and that was the end of it. That seems to not be the case when using a systemd service (which we now have to do because of dbus-broker).

In anycase, if you can handle that 30s+ hang for the sake of testing, you can try out this zip (which also works on my system) that should work with dbus-broker:

~~[email protected]~~

UPDATE

Found a decent way to prevent the hang; here's an up to date zip built from master:

[email protected]

andyholmes on 28 Apr 2018

OK, will do later today (which is probably during your night?) - going on a bike tour with the kids now. However, something weird just happened - I restarted my sytem just now, and suddenly the extension starts up fine and works?! Mind you, this is the version that previously gave me all those error messages, not your newest one with the systemd .service!

Taijian on 28 Apr 2018

Ok, so I tested your latest version and it works! Great job!

Taijian on 28 Apr 2018

👍1

Awesome, well I'm happy for your help getting to the bottom of this, since it was around for some time and pretty hard to figure out without logs for dbus-broker. I've already passed on the gist of the situation to upstream (KDE Connect) so hopefully they don't blindsided by it like I did.

andyholmes on 28 Apr 2018

🎉1 👍1

I confirm it works on NixOS unstable too... but only if I start the daemon manually.

Otherwise, I get the following error...

In looking glass:

Gio.IOErrorEnum: Erreur lors de l’appel de StartServiceByName pour org.gnome.Shell.Extensions.GSConnect : Le délai d’attente est dépassé

In journalctl -f when restarting GNOME Shell:

mai 13 18:15:18 sebastien .gnome-software[2433]: failed to rescan: Failed to parse /home/sebastien/.local/share/applications/org.gnome.Shell.Extensions.GSConnect.desktop file: cannot process file of type application/x-desktop
mai 13 18:15:18 sebastien dbus-daemon[2147]: [session uid=1000 pid=2147] Reloaded configuration
mai 13 18:15:18 sebastien dbus-daemon[2147]: [session uid=1000 pid=2147] Reloaded configuration
mai 13 18:15:18 sebastien dbus-daemon[2147]: [session uid=1000 pid=2147] Activating via systemd: service name='org.gnome.Shell.Extensions.GSConnect' unit='org.gnome.Shell.Extensions.GSConnect.service' requested by ':1.189' (uid=1000 pid=2258 comm="/nix/store/rf2i5i6qpz7gmcmd6hx0cz23xmpdvzjs-gnome-")
mai 13 18:15:18 sebastien systemd[2141]: Failed to load unit "env=XDG_MENU_PREFIX=gnome-", skipping deserialization: Invalid argument
mai 13 18:15:18 sebastien systemd[2141]: Starting GSConnect...
mai 13 18:15:18 sebastien gjs[10146]: JS ERROR: Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found
                                      @resource:///org/gnome/gjs/modules/gettext.js:39:7
                                      @/home/sebastien/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:5:7
mai 13 18:15:18 sebastien env[10146]: Script /home/sebastien/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js threw an exception
mai 13 18:15:18 sebastien systemd[2141]: org.gnome.Shell.Extensions.GSConnect.service: Main process exited, code=exited, status=1/FAILURE
mai 13 18:15:18 sebastien systemd[2141]: org.gnome.Shell.Extensions.GSConnect.service: Failed with result 'exit-code'.
mai 13 18:15:18 sebastien systemd[2141]: Failed to start GSConnect.

It may be related to how NixOS works: the environment is very restricted...

tiramiseb on 13 May 2018

I'm not sure why the .desktop entry would fail to parse, it's pretty straight forward and I've validated it with desktop-file-validate so it should be fine. On the other hand it's not really relevant to launching the service.

On the other hand I've been informed NixOS has some specific requirements for .service files that I'm not sure if I will be able to meet. It apparently uses some wrapper functionality that requires daemon.js to be directly executable, which I've been told by a Gnome developer is unadvised, and may in fact not be permitted by the extensions website. I'll have to try and get in touch with someone connected with the extensions website to find out for sure.

andyholmes on 13 May 2018

Not sure it is related to the .desktop entry: this error may be a side-effect.

I think the real problem here is:

mai 13 18:15:18 sebastien gjs[10146]: JS ERROR: Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found
                                      @resource:///org/gnome/gjs/modules/gettext.js:39:7
                                      @/home/sebastien/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:5:7

... and it may completely be related to how NixOS works : if a dependency is not explicitly declared, it is not available to the executable. GNOME Shell may not have the same environment as me.

You may see here such a dependency problem I fixed for NixOS. I may be able to create a package for NixOS so that we can have a NixOS-specific patch, if the situation is similar (ie. need for a specific import for NixOS).

I have created an issue on the NixOS repository: https://github.com/NixOS/nixpkgs/issues/40474

tiramiseb on 14 May 2018

That might be so. In Gjs library dependencies are declared like this:

imports.gi.versions.Gtk = "3.0";

There are number of issues specific to NixOS raised in #91 before it's ready to be packaged there, unfortunately due to the underlying changes required to support those it probably won't happen until the rewrite is merged into master. Since the primary distribution of shell extensions is the extensions website, which require run-time installation of service and desktop files, the user installation must be supported so that will probably always be the priorty.

andyholmes on 14 May 2018

Haaaa sorry I didn't see that issue, I haven't looked hard enough !

tiramiseb on 14 May 2018

This issue still seems to be present under wayland session, while the extension works fine under Xorg.

I'm also using Arch with dbus-broker, and the issue persists with git master, and the last .zip posted here. Symptoms seem to match everything that's been posted, but here's the error I get during shell startup:

gnome-shell[875]: JS ERROR: Gio.IOErrorEnum: Error calling StartServiceByName for org.gnome.Shell.Extensions.GSConnect: The connection is closed
                            ProxyBase<._init@/usr/share/gnome-shell/extensions/[email protected]/client.js:33:9
                            wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
                            _parent@resource:///org/gnome/gjs/modules/_legacy.js:39:12
                            Daemon<._init@/usr/share/gnome-shell/extensions/[email protected]/client.js:695:9
                            wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
                            SystemIndicator<._serviceVanished@/usr/share/gnome-shell/extensions/[email protected]/extension.js:605:27
                            wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

I can also start the daemon.js from command line without errors.

I can't think of what else might be relevant for debugging at the moment, but let me know if you need additional information or help with testing.

jnsh on 24 May 2018

Could you show me the output from

journalctl -f -o cat /usr/bin/gjs

when gnome-shell is starting the daemon? There shouldn't be any reason the extension would work under Xorg instead of Wayland, other than the plugins that don't work in Wayland. Unless dbus-broker is somehow incompatible with Wayland or DBus activation I'm not sure what is causing this issue.

andyholmes on 24 May 2018

There's nothing in journal from /usr/bin/gjs, since it's still the dbus activation that fails.

However, I just noticed that if I start gnome-shell via GDM, and not directly from command line as I usually do, GSConnect appears to start again under wayland. So my issue doesn't seem to have anything to do with the extension after all. Sorry about the false alarm.

The command I've used to start gnome is XDG_SESSION_TYPE=wayland dbus-run-session gnome-session. I'll try to figure out what's different when logging in with GDM, and report back for others that might encounter this issue.

jnsh on 25 May 2018

Thanks I'd appreciate that. I'm using a pretty standard Ubuntu install so a lot of these issues are hard to diagnose. You might also want to check the status of systemd as it relates to dbus-broker; for example on Ubuntu the dbus-daemon process is:

/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

I'm guessing this is spawned by way of gdm/gnome-session, which maybe doing some session setup that isn't done if gnome-shell is run manually. Using systemd as a middle-man for DBus activation is one of the main differences with dbus-broker and that may be relevant here.

andyholmes on 25 May 2018

I finally had time to take a look at this. First of all my issue doesn't seem to be related to dbus-broker after all: The GSConnect extensions fails to start when I launch shell with XDG_SESSION_TYPE=wayland dbus-run-session gnome-session, even if I disable dbus-broker.

Also, I realized that I never had aforementioned issue with GSConnect v11, even though I was already using dbus-broker. The issue occurred only after I tried testing git-master, and is also reproducible with the last gsconnect.andyholmes.github.io.zip posted above. Therefore it seems that I actually discovered a regression in git master, and it seems reasonable to me, that it could have been caused by the fix to this github issue.

That being said, I also discovered that if I start gnome without dbus-run-session, and merely use XDG_SESSION_TYPE=wayland gnome-session, GSConnect extension starts again without issues. Frankly, I've only been using dbus-run-session, because it's instructed in Arch Wiki (without further explanation why it'd be needed), but according to my initial testing, everything seems to work fine without using it.

jnsh on 29 May 2018

Well dbus-run-session starts dbus-daemon so I guess that must interfere with dbus-broker somehow, since the service scripts should function with either. I would just pick one.

dbus-broker is still considered somewhat unstable, although if you have packages that depend on both then you'll probably have to go with dbus-broker and hope nothing else uses deprecated features.

andyholmes on 29 May 2018

Sorry if my previous comment was unclear. Again, I can reproduce my issue even if I don't use dbus-broker.

I'm not sure if you want to consider this as a bug, since using dbus-run-session when starting gnome-session from command line seems completely unnecessary. However:

Starting gnome-session with dbus-run-session caused no issues with GSConnect v11
The use of dbus-run-session when starting gnome on wayland from command line is recommended in many places, so other users are likely to encounter this issue.

I can open a new issue for this with better description, and/or bisect the commit that caused this if that helps. Although the dbus-broker fixes would seem to be the most likely cause.

jnsh on 29 May 2018

Well, the only real difference with the dbus-broker change is using systemd activation instead of direct DBus activation. This is supported with dbus-daemon anyways as long as systemd is setup properly, but with dbus-broker it's required.

Probably if you start your session with dbus-run-session it's not hooking up to systemd, but if you use gnome-session it uses systemd to start dbus-daemon/dbus-broker. It's really more of a distribution issue, but there really isn't a way for me to support both at the same time. Really, there's no reason to be using dbus-broker yet, but some distributions seem to want to jump the gun on that.

andyholmes on 30 May 2018

I was still wondering why I never experienced issues with dbus-broker and GSConnect v11, and after some investigation realized that v11 works with dbus-broker if I start gnome with dbus-run-session.

Here's again what works, and where dbus activation fails:

Command to start gnome | v11 | v11 w/ dbus-broker | master | master w/ dbus-broker
------------ | ------------- | ------------- | ------------- | -------------
XDG_SESSION_TYPE=wayland exec gnome-session | WORKS | FAILS | WORKS | WORKS
XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session | WORKS | WORKS | FAILS | FAILS

The main difference with the two commands seems to be, that with dbus-run-session the gjs daemon.js process is started under systemd --system session, while it's otherwise started under systemd --user session.

I didn't test every combination with GDM, but my understanding is that the XDG_SESSION_TYPE=wayland exec gnome-session row should apply when logining with it.

I agree that you can count this as distribution issue, but thought I'd share my findings anyway.

I was wondering though, wouldn't the current fix of starting the daemon.js with systemd prevent distributions/users that don't use systemd from using GSConnect?

jnsh on 7 Jun 2018

Thanks for testing those all out, it's odd that v11 works for some with dbus-broker and others it doesn't. It's kind of the main reason I haven't released v12 yet (other than v11 not being reviewed yet) since I'm worried it might break things for some people. I might just have to bite the bullet, although I think v12 will be the last release before I start merging the rewrite into master.

The main difference with the two commands seems to be, that with dbus-run-session the gjs daemon.js process is started under systemd --system session, while it's otherwise started under systemd --user session.

This probably is the problem, now that I think of it. After installing the systemd service file this is run:

systemctl --user daemon-reload

This tells systemctl to rescan for new services files (obviously), but running it with --system is not really doable since it would require root privileges and the script would have to be installed in the system service directory, again being something I can't really check for. I guess once I actually support system installation distros could run that during their post-install phase.

andyholmes on 10 Jun 2018

I'm starting to think whether this could be a bug in dbus-broker.

From https://github.com/bus1/dbus-broker/wiki/Deviations

With dbus-broker, direct activation is no longer supported, rather all activation requests are forwarded to systemd. In case no systemd service has been configured for a given dbus service, a TransientUnit is generated and used instead.

If I understand everything correctly, the bold part means that direct dbus activation should still work with dbus-broker, even without defining SystemdService= in the dbus .service, and a transient unit (which is essentially a temporary systemd service) will run the Exec= line from the dbus service. Unless that wiki page is wrong/out-of-date, I can't think of any reason why that wouldn't happen with the original dbus service in gsconnect v11.

I'm still not sure why starting gnome-session with dbus-run-session prevents issues with v11, but my current guess is that it somehow bypasses dbus-broker altogether, and uses the regular old dbus.

This tells systemctl to rescan for new services files (obviously), but running it with --system is not really doable since it would require root privileges and the script would have to be installed in the system service directory, again being something I can't really check for. I guess once I actually support system installation distros could run that during their post-install phase.

Well, I tried moving theorg.gnome.Shell.Extensions.GSConnect.service from v11 to /usr/share/ (and modified the extension to not recreate it in ~/.local/), but that didn't make any difference.

jnsh on 11 Jun 2018

Quickly glanced trough dbus-broker issues, and there's one that could be related: https://github.com/bus1/dbus-broker/issues/70

I'll investigate this more later, and report to dbus-broker devs if I can reproduce the issue outside gsconnect.

jnsh on 11 Jun 2018

Sorry it took awhile, but now I think I'm finally getting at the root of this issue:

I found out that if I change the Exec= line in org.gnome.Shell.Extensions.GSConnect.service from

Exec=/bin/sh -c "gjs /home/user/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js"

to

Exec=/bin/gjs /home/user/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js

(i.e. remove the /bin/sh -c and call /bin/gjs directly), the direct dbus activation works with dbus-broker, and the extension starts without errors.

Simply removing the /bin/sh -c probably isn't a solution, or even a dirty workaround: It seems that after changing the dbus service file, GSConnect and KDE Connect on my phone don't even see each other any more. @andyholmes, do you have some idea how not starting gjs in separate shell could cause that?

This is probably worth reporting to dbus-broker devs, once I double-check I can reproduce this elsewhere. In any case, I think the systemd service workaround shouldn't be necessary by design when using dbus-broker.

jnsh on 16 Jun 2018

That's some good digging. I've planned to make daemon.js executable and just change the Exec to the file name. The two possible catches are it _may_ require a fixed location for gjs (since I've heard /usr/bin/env is banned in some distros) and it _might_ have to be chmodded at run-time since I'm not confident the extensions website will allow/retain executable bits. The nice thing about sh -c is that PATH is available so just gjs can be invoked, but it's also caused a lot of problems with quoting. I'm assuming you're on Arch (?) and if so is gjs in /usr/bin and/or is /usr/bin/env still permitted on Arch (or your distro)?

With regard to the transient service files dbus-broker is supposed to make, I noticed that too in the documentation, but since I don't (can't?) run dbus-broker in Ubuntu I have no way of telling if it's something I'm doing wrong.

One note about:

Well, I tried moving the org.gnome.Shell.Extensions.GSConnect.service from v11 to /usr/share/ (and modified the extension to not recreate it in ~/.local/), but that didn't make any difference.

There's actually an extra notion of user vs system with systemd. Aside from user vs system install location, there's also ~./local/share/systemd/user vs ~./local/share/systemd/system which is probably what the switches --user and --system refer to, although I'm a bit fuzzy on systemd nomenclature.

andyholmes on 17 Jun 2018

since I've heard /usr/bin/env is banned in some distros

The blog post you linked only states that using #!/usr/bin/env python _shebang_ is forbidden (which makes sense after reading the explanation). There's no mention of the use of the actual /usr/bin/env binary being banned, or even discouraged. I also checked that the /usr/bin/env executable still exists in the latest coreutils package from Fedora.

I'm indeed using Arch, and /usr/bin/env still exists, and I haven't ever heard using it being adviced against. gjs is located in /usr/bin, which is linked to /bin, so either should work.

This Exec line seems to work with dbus-broker, as long as you don't add quotation marks around the gjs command (~~which suggests dbus-broker may just have issues with quotations~~ env doesn't like if you wrap the command around quotations):

Exec=/bin/env gjs /home/user/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js

However, with dbus-broker enabled, that also results in KDE Connect on my phone and GSConnect not seeing each other, while the extension seems to otherwise work perfectly. Does GSConnect use dbus for anything else than activation of daemon.js, or do you other ideas why that could happen?

I'll also test if ~./local/share/systemd/user and ~./local/share/systemd/system work any differently.

jnsh on 17 Jun 2018

I narrowed down the bug in dbus-broker that prevented GSConnect's dbus service activation from working. The fix is waiting for review, and likely included in next release.

However, there appears to be another issue with dbus-broker that prevents GSConnect from working properly: For some reason, the org.gnome.Shell.Extensions.GSConnect interface doesn't get registered with dbus, which obviously causes some issues.

I'll try to figure out some way to easily reproduce this, and report to dbus-broker devs again.

jnsh on 20 Jun 2018

Looks like my final problem with dbus-broker somehow fixed itself, while investigating it today after some hiatus. Can someone else confirm, that there are no issues with GSConnect v11, when using dbus-broker-14?

If no one else reports any problems, I think this issue can be closed.

Commit https://github.com/andyholmes/gnome-shell-extension-gsconnect/commit/86f7015729674179664129f0605a931692727958 can also be reverted, since the bug with dbus service files is fixed in dbus-broker-14.

jnsh on 26 Jul 2018

Well, I for one can confirm that I am using both GSConnect v11 and dbus-broker v14 and they work together perfectly fine.

Taijian on 26 Jul 2018

Sorry I've been not paying attention to this issue much. I've a pushed a reversion of the systemd stuff, with a few other changes. Hopefully this will solve this issue for good, let me know if not since v12 will be the last release of this branch.

Here's a zip:
[email protected]

andyholmes on 13 Aug 2018

Gnome-shell-extension-gsconnect: GSConnect doesn't support dbus-broker

Most helpful comment

All 58 comments

Related issues