Lorsque gnome-shell plante sous Linux Mint 12, il revient généralement en quelques secondes. Quand il ne le fait pas, il semble quil emporte le démon du trousseau de clés avec lui, car après le redémarrage avec
while true; do DISPLAY=:0 gnome-shell --replace; done & il demande la phrase de passe de la clé chaque fois que je lance commandes comme git pull. Comment redémarrer le démon du trousseau de clés (si cest là le problème) lors du redémarrage de gnome-shell?
Réponse
MISE À JOUR: Ces instructions peuvent être obsolètes. Il apparaît sur les systèmes récents que les sockets gnome-keyring ont été déplacés dun répertoire aléatoire de ~/.cache/ vers /run/user/<ID>/keyring/ (à moins sur Debian Jessie), donc un simple redémarrage devrait être suffisant.
Cest un peu délicat car gnome-keyring-daemon définit des paramètres denvironnement uniques avant le démarrage de votre session et cet environnement est utilisé pour accéder au creux du démon un socket. Lenvironnement est copié dans chaque application, il ny a donc aucun moyen de redéfinir toutes les variables denvironnement. manière qui implique de redémarrer manuellement le démon, de faire un lien symbolique entre lancien répertoire et le nouveau (pour que lancien environnement fonctionne toujours) puis de démarrer les services individuels.
-
Assurez-vous quil ny a pas de gnome- keyring-daemon en cours dexécution (cette commande ne doit renvoyer aucun pid, si vous devez le tuer)
pgrep -f gnome-keyring-daemon -
Effacer lancien trousseau de clés sockets
rm -rf ~/.cache/keyring-* -
Démarrez le processus démon – nous utilisons setsid et redirigeons SDTIN, OUT & ERR donc il ny a pas dassociation avec notre shell / tty. Cela créera un nouveau répertoire avec le socket de contrôle dans ~ / .cache /.
setsid /usr/bin/gnome-keyring-daemon </dev/null >/dev/null 2>&1 -
Lien symbolique du nouveau répertoire du socket vers lancien un (idéalement remplacer le caractère générique par le répertoire réel, mais comme nous les avons tous supprimés plus tôt, il ne devrait y en avoir quun):
ln -s ~/.cache/keyring-* $GNOME_KEYRING_CONTROLNB: Je nai pas votre problème gnome-shell, mais si vous ne faites pas exporter ces variables à partir de lendroit où vous démarrez gnome-shell, vous êtes nombreux doivent passer manuellement les variables denvironnement suivantes à gnome-shell:
GPG_AGENT_INFO GNOME_KEYRING_CONTROL SSH_AUTH_SOCK. Vous devriez pouvoir dériver la valeur du chemin supprimé dans # 2 (si vous avez plusieurs répertoires, vous devez rechercher le plus récent). -
Démarrez lautre gnome- services de trousseau de clés (ils se connecteront au démon en utilisant le socket et activeront les services dessus si tout sest bien passé jusquà présent):
/usr/bin/gnome-keyring-daemon --start --components=pkcs11 /usr/bin/gnome-keyring-daemon --start --components=gpg /usr/bin/gnome-keyring-daemon --start --components=sshCes dernières commandes seront imprimées variables denvironnement … vous pouvez les ignorer, assurez-vous simplement quil ny a pas derreurs de connexion de socket.
De plus, si vous voulez nettoyer les anciennes sockets, vous pouvez ajouter un @reboot entrée cron qui effectue un nettoyage:
find ~/.cache/ -maxdepth 1 -type l -name "keyring-*" -delete Commentaires
Réponse
Ceci devrait effectuer un redémarrage propre du démon:
gnome-keyring-daemon -r -d Source: ArchLinux
Commentaires
- A parfaitement fonctionné sur Mint 18 (Sarah). Merci!
- A travaillé dans ubuntu 18.04, merci!
~/.cache/donc ces étapes pouvaient être ignorées; il suffit de tuer et la relance desetsidétait suffisante. La prochaine connexionsshma demandé mon mot de passe correctement et mis en cache comme prévu.