Por que o comando sudo demora para ser executado?

Question

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

Eu adicionei meu usuário à última linha do arquivo / etc / sudoers como mostrado abaixo, para que eu não seja perguntado pela minha senha quando eu executar o comando sudo:

MyUserName ALL=(ALL) NOPASSWD:ALL

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

    

Answer 1

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

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

This happens if you change the hostname during the install process.

To solve the problem, edit the file /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>

    

Answer 2

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. O "mundo Hello" aparece em /var/log/syslog ?

Se este não for o caso, o daemon syslog travou. Reiniciar deve resolver o seu problema.

    

Answer 3

Um dos arquivos / diretórios precisa ser lido em uma montagem em rede ou está, de algum modo, acionando a leitura de um dispositivo usb lento? Tente strace e veja onde está lento; se passar rápido demais, faça

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

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

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

    

Answer 4

Descobri recentemente que tive 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 depois descubra onde as chamadas do sistema estão suspensas.

No meu caso, achei que estava pendurado em uma tradução do DNS, aparentemente, um dos DNSen na minha lista em /etc/resolv.conf era muito buzy ou estava ruim. Então mudei a ordem de resolução e as coisas funcionaram rapidamente de novo.

    

Answer 5

Eu não tenho certeza sobre o Fedora, mas eu usei outros sistemas onde o sudo iria checar de onde você está logado, o que, se o seu DNS não estiver configurado corretamente, pode levar para o tempo limite. Isso também pode ser visto quando SSH'ing para a máquina - é preciso idades para chegar a um prompt.

    

Answer 6

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

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

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

    

Answer 7

Em maiúsculas e minúsculas, é encontrado o nome do host (que foi configurado em /etc/sysconfig / network) não existe no arquivo /etc/hosts ; Então, ao adicionar o arquivo acima mencionado, o arquivo é aberto imediatamente.

    

Answer 8

Eu tive um problema semelhante, corrigi-lo 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.

    

Answer 9

De olhar para o arquivo de exemplo sudoers que eu tenho, eu acredito que deve haver um espaço após o NOPASSWD: bit.

    

Answer 10

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

( fonte )

    

Answer 11

Depois de corrigir qualquer problema com o host, limpe qualquer cache DNS incorreto se você estiver executando um aplicativo de cache DNS como nscd:

/etc/init.d/nscd force-reload

    

Answer 12

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

    

Answer 13

Caso do SELinux

Se o mesmo comando sudo for lento apenas em um daemon e rápido na linha de comando, então é provocado pelo SELinux mais provavelmente. (SELinux = Módulo do kernel Linux aprimorado pela segurança 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 está indo rápido se desativarmos temporariamente a imposição por setenforce 0 . (e depois voltar habilitar 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): Failed to create session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
... sudo[...]: pam_unix(sudo:session): session opened for user root by (uid=0)

O registro de todas as mensagens silenciosas "não-auditoria" do SElinux pode ser ativado por semodule -DB e desabilitado novamente por semodule -B .
(Espero que em breve eu escreva um módulo de políticas SELinux para este caso ou um método de esta resposta possa ser usado. )

    

Answer 14

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

Nesse caso, você provavelmente desejará usar a diretiva de vinculação. Em /etc/ldap/ldap.conf (ou /etc/ldap.conf):

bind_policy soft

    

Answer 15

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