'sudo' comandos são lentos enquanto na rede [fechada]

1

Problema:

  • Os comandos sudo em execução levam até 30 segundos para serem executados. O tempo que leva não é consistente, às vezes o comando retorna rapidamente se foi chamado anteriormente, mas a maior parte do tempo demora muito mais do que deveria. Além disso, quando o sudo é executado enquanto off a rede, ele responde instantaneamente, mas assim que eu conecto a máquina ao meu WIFI, ela fica lenta.

Ambiente

  • OS : Redhat7 Enterprise Linux
  • Hardware: HP Zbook G3
  • A autenticação por cartão inteligente está ativada
  • sudo -V :
  Sudo version 1.8.6p7
  Sudoers policy plugin version 1.8.6p7
  Sudoers file grammar version 42
  Sudoers I/O plugin version 1.8.6p7

Soluções experimentadas, mas com falha:

  • O nome do host está nas duas linhas em / etc / hosts
  • A execução de sudo strace -f -t sudo echo provou que o primeiro sudo é aquele que trava, o segundo comando sudo é executado normalmente conforme o esperado.
  • Alterei as permissões do strace para poder executá-lo como meu nome de usuário, então corri strace -f -t sudo echo e eis que o comando retorna instantaneamente e não é interrompido. Isso é lamentável porque não consigo executar strace no comando sudo para ver onde estou ficando preso.
por user985030 17.05.2017 / 13:44

1 resposta

2

sudo atrasos foram causados por problemas de DNS.

link

Um usuário teve um atraso semelhante de 2 minutos causado pelo problema: link

Portanto, esta é minha primeira linha de investigação. Você pode tentar verificar time getent hosts $(hostname) e ver se há um atraso lá.

Nota: o meu entendimento é que a razão pela qual isso aconteceu foi corrigida pelo autor. Seria muito interessante se você pudesse observar a versão de sudo usada pela sua distribuição. link

Caso contrário, confirme se o problema acontece com o sudo interno de sudo time sudo echo . Então você pode tentar executar sudo strace -t -f sudo echo . Haverá muita saída, mas será timestamp. Você verá uma chamada do sistema em que o atraso é gasto, por exemplo, recvmsg (recebe mensagem, possivelmente esperando com um tempo limite, possivelmente uma resposta DNS). A interpretação completa requer conhecimento de programação. Se algo acontecer via dbus, eu acho que não mostrará qual serviço dbus especificamente. (Sinta-se à vontade para postar a saída completa em algum lugar e criar um link para ela - dropbox.com, gist.github.com, etc).

    
por 17.05.2017 / 14:17

Tags