Gnome-shell-extension-gsconnect: "Waiting for Service..."

[AlbinoGeek]

Describe the bug

Doesn't work out of the box.

Steps To Reproduce:

1. Install GSConnect on Desktop
2. Install KDE Connect on Android
3. Open GSConnect on Desktop
4. Add Desktop's IP in KDE Connect... still doesn't show.
5. Add Android's IP in "Connect to..." in GSConnect... still doesn't show.
6. Click refresh repeatedly in GSConnect... nothing happens.
7. Click refresh repeatedly in KDE Connect... nothing happens.

Expected behavior

Anything other than nothing.

Screenshots

Support Log

GSConnect Version: 39
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: x11
GDMSESSION: gnome
--------------------------------------------------------------------------------
-- Logs begin at Sat 2019-10-12 21:11:21 PDT, end at Tue 2020-06-30 08:50:11 PDT. --
-- No entries --

System Details (please complete the following information):

• GSConnect version: 39
  
  
  
  • Installed from: GNOME Extensions Website
  
  
• GNOME/Shell version: 3.36.3
• Distro/Release: Fedora 32

GSConnect environment (if applicable):

• Paired Device(s): Pixel 2 (not yet paired), Samsung Galaxy S20+ 5G (not yet paired)
• KDE Connect app version: 1.14.2

[rohmishra]

Hey, i noticed you have access to two mobile devices (Pixel 2 and Galaxy S20+). Are you able to connect to one phone from another?

[andyholmes]

Can you please follow the steps for Generating a Support Log as described in the Wiki?

[AlbinoGeek]

@rohmishra "Connect to one phone from another"?

They do not show up in KDE Connect if that's what you're asking,

• I have never had another phone show up on that list.
• Neither phone shows up in GSConnect list.

@andyholmes I did, and it's an empty log (as attached above.)
I repeated all my steps while that dialogue was open, shown below:

Note that the only three lines shown in the log were triggered by my screen recorder [peek] and literally ping.

GSConnect Version: 39
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: x11
GDMSESSION: gnome
--------------------------------------------------------------------------------
-- Logs begin at Sat 2019-10-12 21:11:21 PDT, end at Tue 2020-06-30 13:11:28 PDT. --
Jun 30 13:11:18 gnome-shell[3215]: Recording to /home/damon/.cache/peek/peekTPKPM0.mp4
Jun 30 13:11:25 ModemManager[890]: <warn>  (tty/ttyACM0) at port timed out 3 consecutive times
Jun 30 13:11:28 ModemManager[890]: <warn>  (tty/ttyACM0) at port timed out 4 consecutive times

[AlbinoGeek]

For completionist sake:

• I have the computer firewall firewalld configured to allow all incoming, allow all outgoing
• My phone and computer are both connected over the same 802.11ac Wave 2 WiFi SSID
• My phone does not have any firewall or antivirus software installed, nor is it rooted.

The gif above is the process on the Samsung Galaxy S20+ 5G as remoted through scrcpy
I have repeated the process using my Google Pixel 2 and the same lack of results are shown.

The Trusted Networks section of KDE Connect has Allow all checked.

[rohmishra]

Hmm... that's quite weird I'll have to dig up my old phone to confirm if this is still the case even now but last time I tried, the phones were able to connect to each other.

Is it possible to try starting a hotspot on one of the phones, and then connecting to the phone on the hotspot?

I myself use a pixel and have helped a friend set up his galaxy S8 and the default firmware just works for me.

Is your computer connected via wifi or through ethernet?

Is device isolation disabled on your router/AP?

[andyholmes]

Because the message in the window is "Waiting for service...", we know that the GSConnect service is not running, so trying to connect from a remote device definitely won't work. Trying to connect to a remote device should start the service automatically.

So, what we're looking for is the reason the service is not starting. I'm assuming you've checked that extensions are enabled in gnome-extensions-app/gnome-tweaks, and that you haven't turned off the service in the User Menu.

Since trying to connect via the Preferences didn't work, you will probably have to run the service manually to see the startup error:

$ cd ~/.local/share/gnome-shell/extensions/[email protected]/service
$ ./daemon.js

[AlbinoGeek]

@rohmishra I can confirm the issue has nothing to do with the network setup because...

@andyholmes Running the service manually resulted in the following output:

(GSConnect:3580733): GLib-CRITICAL **: 15:27:43.809: g_variant_new_string: assertion 'string != NULL' failed
(GSConnect:3580733): Gvc-CRITICAL **: 15:27:43.820: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
(GSConnect:3580733): Gvc-CRITICAL **: 15:27:43.820: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed

Which then had my device show up within the software after pressing refresh 1-2 times, then waiting ~10 seconds. The following output was generated after pairing with the device:

Gjs-Message: 15:28:19.752: JS WARNING: [/home/damon/.local/share/gnome-shell/extensions/[email protected]/service/protocol/lan.js 715]: reference to undefined property "GSocketOutputStream"

At this point, the bug is now in regards to the service not being automatically started, and requiring a manual start.

For troubleshooting sake:

• I have made sure the extension is enabled in Gnome Tweaks
• I have tried relogging into my Gnome Session user
• I have tried restarting the Fedora 32 computer

All of which do not result in the service being started, I must start it manually by way of the command you have supplied.

[andyholmes]

Can you confirm that trying to start the service from the User Menu (top-right of the panel) also does not work?

For context, here's how it generally works:

• GSConnect has 2-3 parts.
  
  
  
  • The service
  
  
  • The shell extension (talks to the service over DBus)
  
  
  • The preferences window (talks to the service over DBus)
  
  
• If the service is "enabled" (Turn On in the User Menu), the extension will automatically start the service when the shell extension is enabled (eg. login, screen unlock, enabled in tweaks)
• Whether the service is running or not, clicking refresh in the Preferences window ensures the service gets started.

So assuming the service is enabled, the problem is probably related to DBus activation. In that case, you'll want to try to start the service via DBus and check the system log to find out what the error is. The easiest way to do this is:

$ gapplication launch org.gnome.Shell.Extensions.GSConnect

[AlbinoGeek]

@andyholmes

• Clicking "Turn On" within the extension menu (shown in the system menu) does nothing, (doesn't generate anything in the support log or system log accessed by journalctl -xe.)

---

Pressing "Refresh" in the window also does nothing.

---

As per the supplied command:

[damon@doom service]$ gapplication launch org.gnome.Shell.Extensions.GSConnect
error sending Activate message to application: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

Perhaps this is the issue?

[andyholmes]

Ah, now this rings a bell. There is an issue sometimes with dbus-broker which is usually fixable with:

​$ systemctl reload --user dbus-broker.service

Let me know if that fixes it, and I'll add a wiki note because I keep forgetting about this. I think I've debugged this same issue with people about 6 times 🤔

[theotheroracle]

​$ systemctl reload --user dbus-broker.service

Let me know if that fixes it

it does fix it for me actually .

[andyholmes]

@theotheroracle thanks for reporting, as an aside are you also running Fedora? If so this might be an upstream bug in their systemd package I should report, since I don't recall anyone on other distros reporting it.

I'll try to remember to update the wiki with this as a 1st step before reporting and issue, and close the bug if @AlbinoGeek can confirm this works for them as well.

[theotheroracle]

yeah, i'm on fedora .

[ferdnyc]

Stab taken at updating the "Watiing for Service" troubleshooting section of the wiki.

[andyholmes]

Stab taken at updating the "Watiing for Service" troubleshooting section of the wiki.

Perfect! I like it covers ensuring that's the actual problem, in case there's some other reason this might happen.

[ferdnyc]

@andyholmes Yeah, that's my phobia about cargo cult troubleshooting at work.

Too often, something works once, so people just start doing it by rote — whether it makes sense or not.

If we just posted "try resetting dbus-broker" and left it at that, the bug that causes the problem could be fixed tomorrow, but three years from now we'd still have users resetting it every time there's any problem with GSConnect. Because hey, it worked that one time! 😆

[Akitakek]

Same issue on Fedora.
Reloading dbus-broker.service fixes it.

[andyholmes]

Closing since this is an upstream bug and we've got it covered in the Wiki now.