2

I'm running Gnome 3.22 on a debian stretch, recently installed from scratch, up to date, and since 1 or 2 days ago my custom keyboard shortcuts and some basic actions have had some rather inconvenient delay before actually doing the requested action.

For example, if I try to lower the sound using the Fn + F2 shortcut (keyboard native), nothing happens. Later, at random (by that I mean that I'm not doing anything special, and the delay is not constant but 10s to 3min), the action is performed, and all other "queued" action triggered by shortcuts/other commands are performed all together.

Following this behavior are the following actions:

  • Keyboard action: Sound up/down, Brightness control, Media play/previous/next
  • Custom keyboard shortcut (e.g. I defined Super+Enter to open a new terminal
  • Close session, Shutdown, Reboot from gnome top-right corner menu.
  • Sleep mode hard button on the side of the keyboard

I looked for that kind of problem on the internet, and it is often linked to the gnome-keyring-daemon. (here, there for example). However, the gnome keyring daemon is automatically launched at login, and disabling it did no good.

I don't recall doing anything related to gnome keyring nor session initialisation, and I don't see what caused this behaviour.

Has anyone experienced this issue recently? Solved it? Any idea?

Some details:

yco@xps$ uname -a
Linux xps 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux
yco@xps$ cat /etc/debian_version 
stretch/sid
yco@xps$ gnome-shell --version 
GNOME Shell 3.22.2
yco@xps$ gnome-keyring-daemon --version
gnome-keyring-daemon: 3.20.0
testing: enabled
  • I've been having the exact same problem since 2 days now. This problem started after connecting a second monitor, but disconnecting the monitor and rebooting doesn't help, so I'm lost as well. This is on GNOME Shell 3.18.5. – Serrano Jul 16 '17 at 10:14
  • It happened for the same reasons, except it was shortly after installing a DisplayLink Dock to manage multiple screens. I gave up and changed OS, so I am not able to check your solution. Still, marked it as solved. – yco Jul 17 '17 at 12:10
3

This issue is discussed in more detail at Launchpad bug #1689825.

There the cause of this issues was narrowed down to the following:

I could work around this problem by uninstalling dbus-user-session (and its dependendants xdg-desktop-portal and xdg-desktop-portal-gtk). Those packages came in through flatpak.

This issue started for me right after installing Flatpak on Ubuntu 16.04. The following solution was proposed there:

I uninstalled my flatpak apps, flatpak, and dbus-user-session... then rebooted and all's well. Uninstalling with --purge seems to have taken care of the /etc file markuslet pointed to.

[...]

sudo apt-get purge dbus-user-session
sudo apt-get purge flatpak
sudo apt-get autoremove
sudo reboot

I can confirm that these steps fix the problem, though it's more of a workaround.

If purging of dbus-user-session or flatpak is not an option for you, then there is another workaround that also works:

gnome-keyring-daemon --replace

But you'll have to run this command after each reboot.

  • Actually the very same phenomenon just appeared on my gnome+ubuntu fresh install... Tried your solution, but it didn't work. I haven't dbus-user-session nor flatpak installed though. – yco Jul 24 '17 at 19:59
  • @yco Did you also try the alternative workaround with gnome-keyring-daemon --replace? – Serrano Jul 25 '17 at 22:17
  • yes I did, to no avail :/ I think I got something else conflicting with the gnome-keyring. – yco Jul 26 '17 at 13:21
  • 1
    As weird as it may look, it seems that it was caused by a cups client configuration. Removing the cups client.conf file seems to have done the job so far... – yco Jul 26 '17 at 21:35
0

Strangely enough, in my case it was caused by a CUPS configuration file (/etc/cups/client.conf).

This file was referring to a distant cups server, which was not always reachable. The server was on my work network, thus, when at work, shortcuts and all worked flawlessly, but at home or elsewhere, nothing worked.

I suspect gnome was trying to reach the server and blocking other user functions, then at the request timeout, every queued user call are executed., Still, I have no proof of it (nothing strange in journalctl or anything I was able to find)

Removing this file solved my problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.