GSconnect shows 'waiting for service...'

[pflanzenandi]

Describe the bug

GSconnect shows 'waiting for service...'

Steps To Reproduce:

1. Start GSconnect

Expected behavior

Pairing device option

Screenshots

Support Log

GSConnect Version: 38
GSConnect Install: user
GJS: 16401
XDG_SESSION_TYPE: x11
GDMSESSION: ubuntu
--------------------------------------------------------------------------------
-- Logs begin at Sat 2020-05-16 11:10:16 CEST, end at Sat 2020-05-16 11:15:41 CEST. --
Mai 16 11:15:25 dbus-daemon[1909]: [session uid=1000 pid=1909] Activating service name='org.gnome.gedit' requested by ':1.121' (uid=1000 pid=4895 comm="gjs /home/me/.local/share/gnome-shell/extensions/g" label="unconfined")
Mai 16 11:15:25 dbus-daemon[1909]: [session uid=1000 pid=1909] Successfully activated service 'org.gnome.gedit'
Mai 16 11:15:26 gnome-shell[2237]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4000084
Mai 16 11:15:36 gnome-shell[2237]: ../../../gobject/gsignal.c:2735: instance '0x560dac982f50' has no handler with id '47048'
Mai 16 11:15:37 dbus-daemon[1909]: [session uid=1000 pid=1909] Reloaded configuration
Mai 16 11:15:38 dbus-daemon[1909]: [session uid=1000 pid=1909] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.1' (uid=1000 pid=1902 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Mai 16 11:15:38 systemd[1883]: Starting Tracker metadata database store and lookup manager...
Mai 16 11:15:38 dbus-daemon[1909]: [session uid=1000 pid=1909] Successfully activated service 'org.freedesktop.Tracker1'
Mai 16 11:15:38 systemd[1883]: Started Tracker metadata database store and lookup manager.
Mai 16 11:15:38 fan-speed-control.sh[931]: 36c cold
Mai 16 11:15:38 dbus-daemon[1909]: [session uid=1000 pid=1909] Activating via systemd: service name='org.freedesktop.Tracker1.Miner.Extract' unit='tracker-extract.service' requested by ':1.1' (uid=1000 pid=1902 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Mai 16 11:15:38 systemd[1883]: Starting Tracker metadata extractor...
Mai 16 11:15:38 tracker-extract[5408]: Set scheduler policy to SCHED_IDLE
Mai 16 11:15:38 tracker-extract[5408]: Setting priority nice level to 19
Mai 16 11:15:38 dbus-daemon[1909]: [session uid=1000 pid=1909] Successfully activated service 'org.freedesktop.Tracker1.Miner.Extract'
Mai 16 11:15:38 systemd[1883]: Started Tracker metadata extractor.

System Details (please complete the following information):

• GSConnect version: 38
  • Installed from: GNOME Extensions Website
• GNOME/Shell version: 3.36.2
• Distro/Release: Ubuntu 20.04

GSConnect environment (if applicable):

• KDE Connect app version: 1.14.2

[andyholmes]

You can start the service using the Mobile Devices user menu in GNOME Shell. If you've recently updated GSConnect after Ubuntu, you'll have restart GNOME SHell.

[porjo]

you'll have restart GNOME SHell.

@andyholmes thanks, that worked! This should be added to the Wiki install guide.

(I came here with the same problem after installing on Fedora 32).

[andyholmes]

@porjo there's a small section here. You could add a blurb about OS updates and link there from somewhere easier to find.

You're always welcome to change the Wiki, all you need is your github account :)

[brianjmurrell]

You can start the service using the Mobile Devices user menu in GNOME Shell. If you've recently updated GSConnect after Ubuntu, you'll have restart GNOME SHell.

Is this unavoidable?

I've had this happen again, restarted GNOME Shell and it's still waiting for service. I've tried Turn On repeatedly from the menu and the Settings dialog continues to say waiting for service even after pressing the rescan button on the top left and even closing and re-opening the dialog.

Extensions are not and never were disabled by a crash, etc.

Then I did:

$ 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

and then did:

$ systemctl --user reload dbus-broker.service

which finally made the settings dialog work.

Is all of this palaver really unavoidable? Can these various issues not be corrected?

[andyholmes]

What would you suggest?

[brianjmurrell]

I don't really know as I don't understand the underlying issues that cause the need for so many work-arounds.

Are these to work-around existing bugs in GNOME Shell, and/or DBUS, or other components?

Ultimately you must agree that the process of installing GSconnect could (should) be smoother, yes? I'm just wondering what's preventing that, if you do agree.

[andyholmes]

I'm not sure which workarounds you're referring to exactly. The only command that seems relevant to your problem is:

$ systemctl --user reload dbus-broker.service

Which sometimes happens on a fresh install. Possibly GSConnect is the first user DBus service installed, so dbus-broker is not watching that directory for changes at that time.

[pktiuk]

I think this issue shouldn't be just closed.
For many first time users, it may seem like a bug (The same issue: https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/979 ) .It can be a difficult to find this thread if you don't know English.
After turning on the first time, there should be at least a prompt recommending restarting the device.

[daedaevibin]

I think this issue shouldn't be just closed. For many first time users, it may seem like a bug (The same issue: #979 ) .It can be a difficult to find this thread if you don't know English. After turning on the first time, there should be at least a prompt recommending restarting the device.

Also, side note, on some systems openSSL isn't installed by default (Fedora 41 for example) and you'll need to install that as well.

[ferdnyc]

@pktiuk

After turning on the first time,

...Have to stop you right there. The problem with that is that, just like there's no way for a GNOME Shell extension to know when it's being uninstalled (every deactivation looks the same, whether it's an uninstall, the extension being disabled but not removed, or even just the device going into powersave), there's no way for an extension to know that it's being enabled for the first time. Every activation also looks the same.

there should be at least a prompt recommending restarting the device.

The tricky thing about that is, how do we do it without annoying users who haven't just installed GSConnect?

The other side of that is, for the most part the extension components are only active when they're interacted with. The thing that would run in the background, doing things automatically (like showing notifications to the user) is the service. If it hasn't been started, then there's nothing running to show that prompt.

When in the Preferences app, we have something actively running that can attempt to communicate with the service, and show the "Waiting for service..." message when that communication is not immediately succeeding.

We could maybe do a better job of communicating things to the user, under those conditions. But it's most likely still going to have to be something that happens in response to a user action, like opening Mobile Settings (Preferences), not "automatically" on its own. (Read on for more on that.)

But also, really isn't "try restarting the device" part of EVERY troubleshooting plan, for EVERYTHING? It seems like we really shouldn't have to tell people that, in 2024, though I suppose we can anyway.

But I reserve the right to make the message something sarcastic, like:

@daedaevibin

Also, side note, on some systems openSSL isn't installed by default (Fedora 41 for example) and you'll need to install that as well.

Indeed. GSConnect displays a notification for that situation, if it's detected, at least. But that notification relies on (you guessed it) the service having started.

It was suggested in #1834 that that notification be supplemented with a banner in the main Preferences window, which is a pretty good idea. (Though, that banner would probably still be triggered by the service, which is where the openssl check lives, and therefore would — you guessed it — depend on the service having started.)

Which is why, we could probably also add to that suggestion another Preferences message with advice from our favorite IT person, Roy, for when the "Waiting for service" state occurs.

[ferdnyc]

@pktiuk

After turning on the first time,

...Have to stop you right there. The problem with that is that, just like there's no way for a GNOME Shell extension to know when it's being uninstalled (every deactivation looks the same, whether it's an uninstall, the extension being disabled but not removed, or even just the device going into powersave), there's no way for an extension to know that it's being enabled for the first time. Every activation also looks the same.

there should be at least a prompt recommending restarting the device.

The tricky thing about that is, how do we do it without annoying users who haven't just installed GSConnect?

The other side of that is, for the most part the extension components are only active when they're interacted with. The thing that would run in the background, doing things automatically (like showing notifications to the user) is the service. If it hasn't been started, then there's nothing running to show that prompt.

When in the Preferences app, we have something actively running that can attempt to communicate with the service, and show the "Waiting for service..." message when that communication is not immediately succeeding.

We could maybe do a better job of communicating things to the user, under those conditions. But it's most likely still going to have to be something that happens in response to a user action, like opening Mobile Settings (Preferences), not "automatically" on its own. (Read on for more on that.)

But also, really isn't "try restarting the device" part of EVERY troubleshooting plan, for EVERYTHING? It seems like we really shouldn't have to tell people that, in 2024, though I suppose we can anyway.

But I reserve the right to make the message something sarcastic, like:

@daedaevibin

Also, side note, on some systems openSSL isn't installed by default (Fedora 41 for example) and you'll need to install that as well.

Indeed. GSConnect displays a notification for that situation, if it's detected, at least. But that notification relies on (you guessed it) the service having started.

It was suggested in #1834 that that notification be supplemented with a banner in the main Preferences window, which is a pretty good idea. (Though, that banner would probably still be triggered by the service, which is where the openssl check lives, and therefore would — you guessed it again! — depend on the service having started.)

Which is why, we could probably also add to that suggestion another Preferences message with advice from our favorite IT person, Roy, for when the "Waiting for service" state occurs.

[ferdnyc]

The problem with that is that, just like there's no way for a GNOME Shell extension to know when it's being uninstalled (every deactivation looks the same, whether it's an uninstall, the extension being disabled but not removed, or even just the device going into powersave), there's no way for an extension to know that it's being enabled for the first time. Every activation also looks the same.

(Not strictly, technically, 100% accurate. We could, for example, ship GSConnect with a setting like first_activation that's set to true by default, and set it to false when the service is started for the first time.

But that would only detect that GSConnect has been installed for the first time ever. It'll fail to catch any later reinstallations that occur, ever. It also won't detect extension updates, even though those can also sometimes break the service and necessitate a restart. So, it would be an incredibly fragile detection, probably to the point of rendering it worthless.)

[ferdnyc]

Reopening based on my reluctantly-adopted position that there's more we could be doing about "waiting for service...". Though the actual value of doing more is very much debatable.

[daedaevibin]

Reopening based on my reluctantly-adopted position that there's more we could be doing about "waiting for service...". Though the actual value of doing more is very much debatable.

GSConnect is, in my experience, a valuable tool. I always have an issue attempting to use KDE Connect on Gnome. I have a high tendency to look things up on my phone as well, so sending my clipboard right to my computer is also helping to simplify the work I do in some places. It's an extremely convenient tool.

I'd also like to make it clear it does not seem to function at all with the browser extension for kde connect either. Maybe that's intended though, I wouldn't know.

[pktiuk]

@pktiuk

After turning on the first time,

...Have to stop you right there. The problem with that is that, just like there's no way for a GNOME Shell extension to know when it's being uninstalled (every deactivation looks the same, whether it's an uninstall, the extension being disabled but not removed, or even just the device going into powersave), there's no way for an extension to know that it's being enabled for the first time. Every activation also looks the same.

(As you described in another post) storing these values in settings may be very useful for this purpose. I don't think that detecting reinstallation is a very important issue to tackle, because typical/casual user in 90% of cases will just install an app once and use it. (maybe also file with settings could be also removed during removal process).
But TBH I don't want to dwell too deep into technical details. You should see my message as a regular feedback describing my User Experience with this app.

there should be at least a prompt recommending restarting the device.

The tricky thing about that is, how do we do it without annoying users who haven't just installed GSConnect?

The other side of that is, for the most part the extension components are only active when they're interacted with. The thing that would run in the background, doing things automatically (like showing notifications to the user) is the service. If it hasn't been started, then there's nothing running to show that prompt.

When in the Preferences app, we have something actively running that can attempt to communicate with the service, and show the "Waiting for service..." message when that communication is not immediately succeeding.

We could maybe do a better job of communicating things to the user, under those conditions. But it's most likely still going to have to be something that happens in response to a user action, like opening Mobile Settings (Preferences), not "automatically" on its own. (Read on for more on that.)

There is no need for an external notification, this could be just placed somewhere in the plugin's window. During troubleshooting the first thing you do is not restarting, but investigating settings of the problematic app.

This message could be a part of GUI and could also be translated.

But also, really isn't "try restarting the device" part of EVERY troubleshooting plan, for EVERYTHING? It seems like we really shouldn't have to tell people that, in 2024, though I suppose we can anyway.

Not really, in many issues not. Do you restart your PC, when it does not detect Gamepad you connected? Do you restart PC (or at least browser) after installing a new addon to firefox? No, you just expect it to just run after installation unless it tells you otherwhise (like some Windows installers in the old days when I used Windows).

Remember also about regular, not tech-savvy users which are not used to debugging everything and navigating GitHub (which can be confusing for some people). Moreover, even finding this issue is not easy when you don't set English as a system language.