Por que o comando sudo demora muito para ser executado?

Eu tenho escolhido o Linux (Fedora 10, então 11) nos últimos meses (e gostando imensamente - é como descobrir computadores novamente, tantas coisas para aprender).

Adicionei meu usuário à última linha do arquivo / etc / sudoers, como mostrado abaixo, para que não seja solicitada minha senha ao executar o comando sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Agora, toda vez que executo um comando usando o sudo, ele pausa uma quantidade notável de tempo antes de executar a tarefa (~ 10 segundos). Por que isso pode ser e como posso corrigir isso? Estou executando o Sudo versão 1.7.1 no Fedora 11 x86 64.

Eu fiz essa pergunta no SO e ela foi movida para cá. Dito isto, não tenho mais a capacidade de editar a pergunta como se a possuísse ou até mesmo aceitar a resposta correta, mas essa foi a verdadeira razão pela qual e como resolvê-la:

Encontrado aqui O usuário "rohandhruva" lá dá a resposta certa:

Isso acontece se você alterar o nome do host durante o processo de instalação.

Para resolver o problema, edite o arquivo / etc / hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>

Verifique se o seu daemon syslog está funcionando corretamente; isso causou o problema para mim.

Execute o seguinte comando

logger 'Hello world'

1. O comando retorna dentro de um período de tempo razoável?

2. 'Hello world' aparece /var/log/syslog?

Se não for esse o caso, o daemon syslog travou. Reiniciá-lo deve resolver o seu problema.

É um dos arquivos / diretórios que ele precisa ler em uma montagem em rede ou está de alguma forma ativando a leitura de um dispositivo usb lento? Tente seguir e veja onde é lento; se passar muito rápido, faça

sudo strace -r -o trace.log sudo echo hi

Cada linha começará com o tempo decorrido desde a entrada na chamada do sistema anterior.

(O sudo inicial parece ser necessário; não sei quanto isso perturbará os resultados.)

Recentemente, descobri que tinha o mesmo problema. Não houve atraso no sudo e, de repente, um atraso de 10 a 20 segundos. Eu determinei o problema específico usando:

 1. chmod u+s /usr/sbin/strace  (as the root user)

Como você:

 1. sudo -K
 2. strace sudo /bin/tcsh

E, em seguida, descubra onde as chamadas do sistema estão suspensas.

No meu caso, descobri que ele estava pendurado em uma tradução de DNS, aparentemente um dos DNSen na minha lista /etc/resolv.confestava muito buzy ou com problemas. Então mudei a ordem de resolução e as coisas funcionaram rapidamente novamente.

Não tenho certeza sobre o Fedora, mas usei outros sistemas nos quais o sudo verificava de onde você está conectado, e se o seu DNS não estiver configurado corretamente, pode levar séculos para esgotar o tempo limite. Isso também pode ser visto quando o SSH entra na máquina - leva séculos para surgir um prompt.

Eu tinha o mesmo problema, verifiquei /var/log/auth.log e syslog quanto a erros. Acontece que meu servidor LDAP não pôde ser acessado e diminuiu a velocidade de tudo.

Como não usei mais a autenticação baseada em LDAP, removi todas as referências "ldap" do /etc/nsswitch.conf

Desde então, tudo funciona como um encanto novamente.

Em alguns casos, é encontrado que o nome do host (que foi configurado em /etc/sysconfig/ network) não existe no /etc/hostsarquivo; portanto, ao adicionar o arquivo mencionado acima, o arquivo é aberto imediatamente.

Tive um problema semelhante. Corrigi-o colocando o nome do host (por exemplo, mybox) e a saída completa do comando hostname (mybox.mydomain.com). Isso esclareceu tudo. Passou de 2 minutos para abrir / etc / hosts para acesso instantâneo.

Caso SELinux

Se o mesmo comando sudo for lento apenas em um daemon e rápido na linha de comando, é provavelmente o SELinux mais provavelmente. (SELinux = módulo do kernel Linux com segurança avançada da NSA, ativado no Fedora por padrão.)

Um caso típico é um servidor http e um script especial para gerenciamento de servidor, restrito em sudoers:

apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command

É típico, neste caso, que nada sobre o SELinux seja relatado no log de auditoria ausearch -m avc -ts today, mas o script será rápido se desativarmos temporariamente a imposição por setenforce 0. (e depois ativar novamente por setenforce 1)

As únicas mensagens relevantes no log do sistema (journalcrl) são estas após o atraso de 25 segundos:

... sudo [...] pam_systemd (sudo: session): falha ao criar a sessão: não recebeu uma resposta. As possíveis causas incluem: o aplicativo remoto não enviou uma resposta, a política de segurança do barramento de mensagens bloqueou a resposta, o tempo limite da resposta expirou ou a conexão de rede foi interrompida.
... sudo [...]: pam_unix (sudo: sessão): sessão aberta para raiz do usuário por (uid = 0)

O registro de todas as mensagens silenciosas do SElinux "não faça auditoria" pode ser ativado semodule -DBe desativado novamente por semodule -B.
(Espero escrever em breve um módulo de política do SELinux em breve para este caso aqui ou um método dessa resposta pode ser usado.)

Olhando para o sudoersarquivo de amostra que tenho, acredito que deveria haver um espaço após o NOPASSWD:bit.

Verifique seu arquivo / etc / hosts e verifique se você tem uma entrada para 127.0.0.1

( fonte )

Após corrigir qualquer problema no host, limpe qualquer cache DNS incorreto se estiver executando um aplicativo de cache DNS como o nscd:

/etc/init.d/nscd force-reload

Para mim, foi instalado o krb5-user / config / locales. Percebi isso examinando /var/log/auth.log. Usando o apt-get remove para desinstalar esses pacotes, foi corrigido. Não remova esses pacotes se você estiver em um computador que requer o kerberos (pam_krb5) obviamente.

Você está usando LDAP para autenticação?

Nesse caso, você provavelmente deseja usar a política de ligação virtual. Em /etc/ldap/ldap.conf (ou /etc/ldap.conf):

bind_policy soft

Parece que você tem algum tipo de tempo limite na sua cadeia de autenticação. Veja como o sudo tenta se autenticar e observe gargalos.

Caso Systemd

Para mim, meu sistema ficou sem memória e muitos processos travaram. Meu sistema é baseado no systemd e algo ali havia travado. É difícil lembrar tudo o que fiz, mas:

• systemctl status <any.service> expiraria
• Não consegui sudo reboot(baseado no sistema)

Solução

Uma reinicialização corrigiu meu problema, mas para mim foi apenas um bandaid. Você ainda precisa descobrir por que ficou sem memória / travou.