Como iniciar o daemon do chaveiro após uma falha do shell do gnome?

ATUALIZAÇÃO: Estas instruções podem estar obsoletas. Parece que em sistemas recentes os soquetes do gnome-keyring movidos de um diretório aleatório em ~/.cache/ para /run/user/<ID>/keyring/ (em menos no Debian Jessie), então uma reinicialização simples deve ser suficiente.

É um pouco complicado, já que o gnome-keyring-daemon define parâmetros de ambiente exclusivos antes de sua sessão iniciar e este ambiente é usado para acessar o daemon através um soquete. O ambiente é copiado para todos os aplicativos, portanto não há como redefinir todas as variáveis de ambiente. forma que envolve reiniciar manualmente o daemon, vincular simbolicamente o diretório antigo ao novo (para que o ambiente antigo ainda funcione) e, em seguida, iniciar os serviços individuais.

1. Certifique-se de que não haja gnome- keyring-daemon em execução (este comando não deve retornar nenhum pid, se precisar, você precisa eliminá-lo)

   pgrep -f gnome-keyring-daemon 

2. Limpar o chaveiro antigo sockets

   rm -rf ~/.cache/keyring-* 

3. Inicie o processo daemon – usamos setsid e redirecionamos SDTIN, OUT & ERR então não há associação com nosso shell / tty. Isso criará um novo diretório com soquete de controle em ~ / .cache /.

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

4. Vincule simbolicamente o novo diretório de soquete ao antigo um (de preferência substitua o curinga pelo diretório real, mas como removemos todos antes, deve haver apenas um):

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

   NB: Não tenho o seu problema com o gnome-shell, mas se você não tiver essas variáveis exportadas de onde você inicia o gnome-shell, muitos precisa passar manualmente as seguintes variáveis de ambiente para o gnome-shell: GPG_AGENT_INFO GNOME_KEYRING_CONTROL SSH_AUTH_SOCK. Você deve ser capaz de derivar o valor do caminho excluído em # 2 (se você tiver vários diretórios, precisa procurar o mais recente).

5. Inicie o outro gnome- serviços de chaveiro (eles se conectarão ao daemon usando o soquete e habilitarão os serviços nele se tudo correr bem até agora):

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

   Estes últimos comandos serão impressos variáveis de ambiente … você pode ignorá-las, apenas certifique-se de que não haja erros de conexão de soquete.

Além disso, se quiser limpar soquetes antigos, você pode adicionar um @reboot entrada cron que faz uma limpeza:

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

Comentários

• No CentOS 7.3 / gnome-keyring 3.14, não havia nada relacionado ao chaveiro em ~/.cache/, portanto, essas etapas poderiam ser ignoradas; apenas matar e o setsid relançar foi suficiente. Em seguida, ssh login pediu minha senha corretamente e armazenou em cache conforme o esperado.
• Na verdade, eu não ' não tenho nenhuma mais arquivos de chaveiro desde julho de 2015 que parecem corresponder à minha atualização do Debian 7 / Wheezy para o 8 / Jessie. Eu parei de depender do daemon do chaveiro mesmo antes disso, então eu não ' nem sei como ele ' deve funcionar agora.

Isso deve executar uma reinicialização limpa do daemon:

gnome-keyring-daemon -r -d 

Fonte: ArchLinux

Comentários

• Funcionou perfeitamente no Mint 18 (Sarah). Obrigado!
• Funcionou no ubuntu 18.04, obrigado!