Pourquoi la commande sudo tarde-t-elle à s'exécuter?

J'ai adopté Linux (Fedora 10, puis 11) au cours des derniers mois (et en ai profité énormément - c'est comme si on découvrait des ordinateurs à nouveau, tellement de choses à apprendre).

J'ai ajouté mon utilisateur à la dernière ligne du fichier / etc / sudoers, comme indiqué ci-dessous, afin de ne pas recevoir mon mot de passe lorsque j'exécute la commande sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Désormais, chaque fois que j'exécute une commande à l'aide de sudo, il s'interrompt assez longtemps avant d'exécuter la tâche (environ 10 secondes). Pourquoi est-ce possible et comment puis-je résoudre ce problème? J'utilise Sudo version 1.7.1 sur Fedora 11 x86 64.

J'ai posé cette question sur SO et cela a été déplacé ici. Cela dit, je ne suis plus en mesure de modifier la question comme si je la possédais, ni même d'accepter la réponse correcte, mais cela s'est avéré être la véritable raison pour laquelle et comment le résoudre:

Ici, l' utilisateur "rohandhruva" trouve la bonne réponse:

Cela se produit si vous modifiez le nom d'hôte au cours du processus d'installation.

Pour résoudre le problème, éditez le fichier / 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>

Vérifiez que votre démon syslog fonctionne correctement. cela a causé le problème pour moi.

Lancer la commande suivante

logger 'Hello world'

1. Est-ce que la commande revient dans un délai raisonnable?

2. 'Bonjour tout le monde' apparaît-il /var/log/syslog?

Si ce n'est pas le cas, le démon syslog s'est écrasé. Le redémarrer devrait résoudre votre problème.

L'un des fichiers / répertoires qu'il doit lire sur un montage en réseau ou déclenche-t-il en quelque sorte la lecture à partir d'un périphérique USB lent? Essayez strace et voyez où c'est lent; si ça passe trop vite, fais

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

Chaque ligne commence par le temps écoulé depuis la saisie du précédent appel système.

(Le sudo initial semble être nécessaire; je ne sais pas dans quelle mesure cela va perturber les résultats.)

J'ai récemment constaté que j'avais le même problème. Il n'y avait pas eu de retard sudo et tout d'un coup, environ 10 à 20 secondes. J'ai déterminé le problème spécifique en utilisant:

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

Comme vous-même:

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

Et trouvez ensuite où les appels système sont en attente.

Dans MON cas, j’ai trouvé qu’il était en attente d’une traduction DNS. Apparemment, l’un des DNSen de ma liste /etc/resolv.confétait très animé ou a mal tourné. J'ai donc changé l'ordre de résolution et les choses ont vite fonctionné.

Je ne suis pas sûr à propos de Fedora, mais j'ai utilisé d'autres systèmes sur lesquels sudo vérifierait d'où vous êtes connecté. Si votre DNS n'est pas configuré correctement, le délai peut être long. Cela se voit également lorsque SSH entre dans la machine - il faut beaucoup de temps pour arriver à une invite.

J'ai le même problème, j'ai vérifié les erreurs dans /var/log/auth.log et syslog. Il s'avère que mon serveur LDAP n'a pas pu être atteint et cela a tout ralenti.

Je n'utilisais plus l'authentification basée sur LDAP, j'ai donc supprimé toutes les références "ldap" de /etc/nsswitch.conf

Depuis lors, tout fonctionne à nouveau comme un charme.

Dans certains cas, il se trouve que le nom d’hôte (qui a été configuré dans /etc/sysconfig/ network) n’existe pas dans le /etc/hostsfichier; Ainsi, lors de l'ajout du fichier susmentionné, le fichier s'ouvre rapidement.

J'ai eu un problème similaire, je l'ai résolu en plaçant le nom d'hôte (par exemple, mybox) et la sortie complète de la commande hostname (mybox.mydomain.com). Cela l'a éclairci. Allé de 2 minutes pour ouvrir / etc / hosts à un accès instantané.

Affaire SELinux

Si la même commande sudo est lente uniquement dans un démon et rapide sur la ligne de commande, cela est probablement causé par SELinux . (SELinux = module du noyau Linux Security-Enhanced NSA, activé par défaut dans Fedora.)

Un cas typique est un serveur http et un script spécial pour la gestion de serveur, restreint à sudoers:

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

Il est typique dans ce cas que rien ne concerne SELinux dans le journal d'audit ausearch -m avc -ts today, mais le script se déroule rapidement si nous désactivons temporairement l'application par setenforce 0. (puis de nouveau activé par setenforce 1)

Les seuls messages pertinents dans le journal système (journalcrl) sont ceux-ci après le délai de 25 secondes:

... sudo [...] pam_systemd (sudo: session): Echec de la création de session: N'a pas reçu de réponse. Les causes possibles sont les suivantes: l’application distante n’a pas envoyé de réponse, la stratégie de sécurité du bus de messages a bloqué la réponse, le délai de réponse a expiré ou la connexion réseau a été rompue.
... sudo [...]: pam_unix (sudo: session): session ouverte pour l'utilisateur root par (uid = 0)

La journalisation de tous les messages silencieux "sans audit" de SElinux peut être activée semodule -DBet désactivée de nouveau semodule -B.
(J'espère que j'écrirai bientôt un module de politique SELinux bientôt pour ce cas ou une méthode de cette réponse pourra être utilisée.)

En examinant le sudoersfichier exemple que j'ai, je pense qu'il est censé y avoir un espace après le NOPASSWD:bit.

Vérifiez votre fichier / etc / hosts et assurez-vous que vous avez une entrée pour 127.0.0.1

( source )

Après avoir résolu les problèmes d'hôte, assurez-vous d'effacer tout cache DNS défectueux si vous exécutez une application de mise en cache DNS telle que nscd:

/etc/init.d/nscd force-reload

Pour moi, c’est krb5-user / config / locales en cours d’installation. J'ai remarqué cela en examinant /var/log/auth.log. Utiliser apt-get remove pour désinstaller ces paquets l'a corrigé. Ne supprimez pas ces paquets si vous êtes sur un ordinateur nécessitant kerberos (pam_krb5) évidemment.

Utilisez-vous LDAP pour l'authentification?

Si tel est le cas, vous souhaiterez probablement utiliser une stratégie de liaison souple. Dans /etc/ldap/ldap.conf (ou /etc/ldap.conf):

bind_policy soft

On dirait que vous avez une sorte de délai d'attente dans votre chaîne d'authentification. Vérifiez comment sudo tente de s'authentifier et surveillez les goulots d'étranglement.

Affaire Systemd

Pour moi, mon système était à court de mémoire et de nombreux processus se sont bloqués. Mon système est basé sur systemd et quelque chose s’est écrasé. Il m'est difficile de me souvenir de tout ce que j'ai fait, mais:

• systemctl status <any.service> expirerait
• Je ne pouvais pas sudo reboot(basé sur systemd)

Solution

Un redémarrage a corrigé mon problème, mais pour moi, ce n'était qu'un pansement. Vous devez toujours découvrir pourquoi vous avez manqué de mémoire / bloqué.