ssh-search-provider doesn't work for new login session until disabled and enabled
dhwalker opened this issue · comments
In Gnome 3.38 / openSUSE Tumbleweed, attempts to find an ssh host after logging into a new session result in only "Searching..." displayed on the screen. Disabling and enabling the extension fixes the problem for the rest of the session; matching ssh hosts are shown on the screen and can be selected.
Thank you for reporting the issue.
Can you please:
- Enable debug logging for the extension:
- Launch Gnome Tweaks
- In the Extensions pane, find SSH search provider reborn
- Click the gear icon.
- Toggle the debug button to on.
- Now reproduce the problem:
For example remove a host from~/.ssh/known_hosts, restart gnome shell, login on this host and try to find the host using gnome shell. - After having reproduced the problem, attach to this bug the output of:
journalctl -S '5 minutes ago'(assuming you've reproduced the problem within the 5 minutes before runningjournalctl)ls -la ~/.ssh
Thanks for your quick reply.
I think I wasn't clear about the problem I'm having. The "session" I referred to in my original post is the Gnome session that's running ssh-search-provider, not the ssh session, and I'm searching for a host that's already in my known_hosts. Figuring you though I meant a session with a new ssh host in your instructions to reproduce the problem, here's what I've done instead:
- Toggled ssh-search-provider's debug button on.
- Logout my Gnome session and log back in (to restart gnome-shell, as I'm using Wayland).
- Search for "fitlet2". I waited longer than usual and saw that "Searching..." changed to "No results" after a while.
- Create journalctl.txt and ls-ssh.txt per your step 3.
- In Gnome Tweaks, disable then enable ssh-search-provider.
- Search for "fitlet2". This time it's found, I can select it, and I get a gnome-terminal window logged into fitlet2.
- Create journalctl2.txt and ls-ssh2.txt.
I hope this helps. If you still want me to follow your step 2, let me know.
OK. If I understand your symptoms, you're saying that after logging in a Gnome session, SSH Search Provider isn't able to complete any hosts until it is toggled off and back on.
That is consistent with what I'm seeing in the log files: in journalctl2.txt I can see that you are performing a search:
journalctl2.txt:Jan 02 15:49:29 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getInitialResultSet(fi)
journalctl2.txt:Jan 02 15:49:29 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getInitialResultSet(fi) = 1[fitlet2]
journalctl2.txt:Jan 02 15:49:29 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.filterResults(5)
journalctl2.txt:Jan 02 15:49:29 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getResultMetas(fitlet2)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitl)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitl) = 1[fitlet2]
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.filterResults(5)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitlet)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitlet) = 1[fitlet2]
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.filterResults(5)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitlet2)
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.getSubsearchResultSet(fitlet2) = 1[fitlet2]
journalctl2.txt:Jan 02 15:49:30 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.filterResults(5)
journalctl2.txt:Jan 02 15:49:31 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.activateResult(fitlet2)
journalctl2.txt:Jan 02 15:49:31 homelap7 gnome-shell[28940]: Ssh-Search-Provider: SshSearchProvider.activateResult(): cmd=gnome-terminal,--,ssh,fitlet2
However, I don't see any trace of such a search in journalctl.txt.
This seems to indicate that either:
-
Gnome-shell is buggy and doesn't pass the search to the SSH Search Provider
or
-
Something messes with the search provider list.
Can you try to rule out [1] by:
- disabling all extensions except SSH search provider reborn
- logging out and back in
- does the problem still happen?
When the problem is occurring, can you open looking glass (ALT-f2 lg with default keybindings, then type this expression in the javascript console:
var iter=Main.overview.viewSelector._searchResults._providers.values(); var a = []; while(1) { var d = iter.next(); if (d.done) break; a.push(d.value.id); }; aThis will print something like:
r(0) = a-very-long-line
Click on the value (eg. a-very-long-line in the example above to get it broken down. Your screen should look like this:
Please attach a screenshot, or report if you see ssh-search-provider@extensions.gnome-shell.fifi.org in the list (in my screenshot, it is the last).
Yes, your understanding of my symptoms is correct.
Disabling all extensions except for SSH Search Provider Reborn didn't change anything. The information from Looking Glass, though, was interesting. If I display that information immediately after logging in, it doesn't show ssh-search-provider@extensions.gnome-shell.fifi.org on the list:
After using Tweaks to disable and enable it, though, it's on the list:
The interesting thing is that the pre-disable/enable list has org.gnome.Terminal.desktop at position 12, which is where ssh-search-provider shows up after disable/enable.
I think it may be fixed with the latest release (v8).
Would you mind checking?
For the record, the fix is to work around a bug in Gnome Shell. But it's working now.