When gnome-shell crashes on Linux Mint 12 it usually comes up again within a couple seconds. When it doesn't, it seems that it takes the keyring daemon with it, because after restarting with

while true; do DISPLAY=:0 gnome-shell --replace; done &

it asks for the key passphrase every time I run commands like git pull. How do I restart the keyring daemon (if that's what the problem is here) when restarting gnome-shell?


This should perform a clean reboot of the daemon:

gnome-keyring-daemon -r -d

Source: ArchLinux

  • 1
    Worked perfectly on Mint 18 (Sarah). Thanks!
    – drew010
    Jul 20 '17 at 18:07
  • Worked in ubuntu 18.04, thanks!
    – TNT
    Apr 15 '20 at 9:10

UPDATE: These instructions may be obsolete. It appears on recent systems the gnome-keyring sockets moved form a random directory in ~/.cache/ to /run/user/<ID>/keyring/ (at least on Debian Jessie), so a simple restart should be sufficient.

It's a bit tricky as gnome-keyring-daemon sets unique environment parameters before your session starts and this environment is used to access the daemon trough a socket. The environment is copied to every application so there is no way to re-set all environment variables. There's a way which involves manually restarting the daemon, symlinking the old dir to the new one (so the old environment still works) and then starting the individual services.

  1. Ensure there are no gnome-keyring-daemon running (this command should return no pid, if it does you need to kill it)

    pgrep -f gnome-keyring-daemon
  2. Clear old keyring sockets

    rm -rf ~/.cache/keyring-*
  3. Start the daemon process - we use setsid and redirect SDTIN, OUT & ERR so there's no association to our shell/tty. This will create a new directory with control socket in ~/.cache/.

    setsid /usr/bin/gnome-keyring-daemon </dev/null >/dev/null 2>&1
  4. Symlink the new socket directory to the old one (ideally replace the wildcard with the actual directory, but since we removed them all earlier there should be only one):

    ln -s ~/.cache/keyring-* $GNOME_KEYRING_CONTROL

    NB: I don't have your gnome-shell issue, but if you don't have these variables exported from where you start gnome-shell you many need to manually pass the following environment variables to gnome-shell: GPG_AGENT_INFO GNOME_KEYRING_CONTROL SSH_AUTH_SOCK. You should be able to derive the value from the path deleted in #2 (if you have multiple directories you need to look for the most recent).

  5. Start the other gnome-keyring services (they will connect to the daemon using the socket and enable the services on it if all went fine so far):

    /usr/bin/gnome-keyring-daemon --start --components=pkcs11
    /usr/bin/gnome-keyring-daemon --start --components=gpg
    /usr/bin/gnome-keyring-daemon --start --components=ssh

    These last commands will print environment variables... you can ignore them, just make sure there are no socket connection errors.

Also, if you want to cleanup old sockets you can add a @reboot cron entry that does a cleanup:

find ~/.cache/ -maxdepth 1 -type l -name 'keyring-*' -delete
  • On CentOS 7.3 / gnome-keyring 3.14, there was nothing related to the keyring in ~/.cache/ so those steps could be skipped; just killing and the setsid re-launch was sufficient. Next ssh login asked me for my password properly and cached as expected. Feb 13 '17 at 20:21
  • Indeed I don't have any more keyring- files since July 2015 which seems to correspond to my upgrade from Debian 7/Wheezy to 8/Jessie. I stopped relying on the keyring daemon even before that, so I don't even know how it's supposed to work now. Feb 15 '17 at 6:59

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.