Início / server / Perguntas / 38114
Accepted
4 revs, 3 users 40%anon
Asked: 2009-07-09 19:51:12 +0800 CST

Por que o comando sudo demora muito para ser executado?

  • 772

Eu tenho adquirido o Linux (Fedora 10, depois 11) nos últimos meses (e gostando imensamente - é como descobrir computadores de novo, tantas coisas para aprender).

Adicionei meu usuário à última linha do /etc/sudoersarquivo, conforme mostrado abaixo, para que não seja solicitada minha senha ao executar o sudocomando:

MyUserName ALL=(ALL) NOPASSWD:ALL

Agora, toda vez que executo um comando usando sudo, ele pausa uma quantidade notável de tempo antes de realmente 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.

linux permissions sudo

16 respostas

  1. Best Answer

    Fiz essa pergunta no SO e ela foi movida para cá. Dito isso, não tenho mais a capacidade de editar a pergunta como se fosse minha, ou até mesmo aceitar a resposta correta, mas esse acabou sendo o verdadeiro motivo e como resolvê-lo:

    Encontrado aqui O usuário "rohandhruva" 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>
    • 173

  2. Verifique se 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. O 'Hello world' aparece em /var/log/syslog?

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

    • 28

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

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

    Cada linha começará com o tempo gasto desde a entrada na syscall anterior.

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

    • 13

  4. Recentemente descobri que estava com o mesmo problema. Não houve atraso sudo e, de repente, cerca 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ê mesmo:

     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 estava pendurado em uma tradução de DNS, aparentemente um dos DNSen da minha lista /etc/resolv.confestava muito cheio ou com problemas. Então eu mudei a ordem de resolução e as coisas funcionaram rapidamente novamente.

    • 11

  5. Eu tive o mesmo problema, verifiquei /var/log/auth.log e syslog para erros. Acontece que meu servidor LDAP não pôde ser alcançado e deixou tudo mais lento.

    Eu não usava mais a autenticação baseada em LDAP, então removi todas as referências "ldap" de /etc/nsswitch.conf

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

    • 7

  6. Não tenho certeza sobre o Fedora, mas usei outros sistemas em que o sudo verificaria de onde você está conectado, o que, se o seu DNS não estiver bem configurado, pode levar muito tempo para expirar. Isso também pode ser visto ao fazer SSH na máquina - leva séculos para aparecer um prompt.

    • 5

  7. No meu caso, o hostname (que foi configurado em /etc/sysconfig/network) não existia no /etc/hostsarquivo; então, ao adicioná-lo ao arquivo mencionado, o arquivo é aberto imediatamente.

    • 5

  8. Eu tive um problema semelhante, consertei 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.

    • 3

  9. Caso SELinux

    Se o mesmo comando sudo for lento apenas em um daemon e rápido na linha de comando, provavelmente será causado pelo SELinux . (SELinux = módulo de kernel Linux com segurança aprimorada da NSA, habilitado 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 está indo rápido se desabilitarmos temporariamente a imposição por setenforce 0. (e depois habilitar de volta 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 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 de resposta expirou ou a conexão de rede foi interrompida.
    ... sudo[...]: pam_unix(sudo:session): sessão aberta para usuário root por (uid=0)

    O registro de todas as mensagens silenciosas de "não auditar" do SElinux pode ser habilitado semodule -DBe desabilitado novamente por semodule -B.
    (Espero escrever em breve um módulo de política SELinux em breve para este caso aqui ou um método desta resposta possa ser usado.)

    • 3

  10. Verifique seu arquivo /etc/hosts e certifique-se de ter uma entrada para 127.0.0.1

    ( fonte )

    • 2

relate perguntas