¿Cómo iniciar el demonio del llavero después de un bloqueo de gnome-shell?

ACTUALIZACIÓN: Estas instrucciones pueden estar obsoletas. Parece que en los sistemas recientes los sockets de gnome-keyring se movieron de un directorio aleatorio en ~/.cache/ a /run/user/<ID>/keyring/ (en menos en Debian Jessie), por lo que un simple reinicio debería ser suficiente.

Es un poco complicado ya que gnome-keyring-daemon establece parámetros de entorno únicos antes de que comience la sesión y este entorno se usa para acceder al canal del demonio un socket. El entorno se copia en cada aplicación, por lo que no hay forma de restablecer todas las variables de entorno. Hay «sa forma que implica reiniciar manualmente el demonio, enlazar el directorio antiguo con el nuevo (para que el entorno antiguo siga funcionando) y luego iniciar los servicios individuales.

1. Asegúrese de que no haya gnome- keyring-daemon en ejecución (este comando no debe devolver ningún pid, si es así, debe eliminarlo)

   pgrep -f gnome-keyring-daemon 

2. Limpiar el llavero antiguo sockets

   rm -rf ~/.cache/keyring-* 

3. Inicie el proceso del demonio – usamos setsid y redirigimos SDTIN, OUT & ERR por lo que no hay asociación a nuestro shell / tty. Esto creará un nuevo directorio con socket de control en ~ / .cache /.

   setsid /usr/bin/gnome-keyring-daemon </dev/null >/dev/null 2>&1 

4. Enlace simbólico del nuevo directorio de socket al antiguo uno (lo ideal es reemplazar el comodín con el directorio real, pero como los eliminamos todos antes, debería haber solo uno):

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

   NB: No tengo su problema de gnome-shell, pero si no tiene estas variables exportadas desde donde comienza gnome-shell, muchos necesita pasar manualmente las siguientes variables de entorno a gnome-shell: GPG_AGENT_INFO GNOME_KEYRING_CONTROL SSH_AUTH_SOCK. Debería poder derivar el valor de la ruta eliminada en el n. ° 2 (si tiene varios directorios, debe buscar el más reciente).

5. Inicie el otro gnome- servicios de llavero (se conectarán al demonio usando el socket y habilitarán los servicios en él si todo ha ido bien hasta ahora):

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

   Estos últimos comandos se imprimirán variables de entorno … puede ignorarlas, solo asegúrese de que no haya errores de conexión de socket.

Además, si desea limpiar sockets antiguos, puede agregar un @reboot entrada cron que realiza una limpieza:

find ~/.cache/ -maxdepth 1 -type l -name "keyring-*" -delete 

Comentarios

• En CentOS 7.3 / gnome-keyring 3.14, no había nada relacionado con el anillo de claves en ~/.cache/ por lo que esos pasos podrían omitirse; simplemente matar y el setsid relanzamiento fue suficiente. Siguiente ssh login me pidió mi contraseña correctamente y se guardó en caché como se esperaba.
• De hecho, no ' más archivos de llavero desde julio de 2015, que parece corresponder a mi actualización de Debian 7 / Wheezy a 8 / Jessie. Dejé de confiar en el demonio del anillo de claves incluso antes de eso, así que ' ni siquiera sé cómo ' se supone que funciona ahora.

Esto debería realizar un reinicio limpio del demonio:

gnome-keyring-daemon -r -d 

Fuente: ArchLinux

Comentarios

• Funcionó perfectamente en Mint 18 (Sarah). ¡Gracias!
• Trabajó en ubuntu 18.04, ¡gracias!