Pourquoi la commande Sudo est-elle longue à exécuter?
J'ai pris Linux (Fedora 10, puis 11) au cours des derniers mois (et j'ai énormément apprécié - c'est comme redécouvrir les ordinateurs, 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 me demander 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, elle marque une pause notable avant d'exécuter la tâche (~ 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 elle a été déplacée ici. Cela dit, je n'ai plus la possibilité de modifier la question comme si je la possédais, ni même d'accepter la bonne réponse, mais cela a tourné être la vraie raison et comment le résoudre:
Trouvé ici L'utilisateur "rohandhruva" donne la bonne réponse:
Cela se produit si vous modifiez le nom d'hôte pendant le processus d'installation.
Pour résoudre le problème, modifiez 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.
Exécutez la commande suivante
logger 'Hello world'
La commande revient-elle dans un délai raisonnable?
Est-ce que 'Hello world' apparaît dans
/var/log/syslog?
Si ce n'est pas le cas, le démon syslog s'est bloqué. Le redémarrer devrait résoudre votre problème.
L'un des fichiers/répertoires doit-il être lu sur un support 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, faites
Sudo strace -r -o trace.log Sudo echo hi
Chaque ligne commencera avec le temps écoulé depuis la saisie de l'appel système précédent.
(Le Sudo initial semble être nécessaire; je ne sais pas à quel point cela va perturber les résultats.)
J'ai récemment découvert que j'avais le même problème. Il n'y avait pas eu de retard de Sudo et puis tout d'un coup, environ 10-20 secondes de retard. J'ai déterminé le problème spécifique en utilisant:
1. chmod u+s /usr/sbin/strace (as the root user)
Comme vous:
1. Sudo -K
2. strace Sudo /bin/tcsh
Et puis trouvez où les appels système sont suspendus.
Dans MON cas, j'ai trouvé qu'il était suspendu à une traduction DNS, apparemment l'un des DNSen dans ma liste sur /etc/resolv.conf était très bruyant ou a mal tourné. J'ai donc changé l'ordre de résolution et les choses pouf ont fonctionné à nouveau rapidement.
Je hade le même problème, j'ai vérifié les erreurs /var/log/auth.log et syslog. Il s'avère que mon serveur LDAP n'a pas pu être atteint et il a tout ralenti.
Je n'utilisais plus d'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 s'agit du nom d'hôte (qui a été configuré dans /etc/sysconfig/réseau) n'existe pas dans /etc/hosts fichier; ainsi, lors de l'ajout du fichier susmentionné, le fichier s'ouvre rapidement.
Je ne suis pas sûr de Fedora, mais j'ai utilisé d'autres systèmes où Sudo vérifierait d'où vous êtes connecté, ce qui, si votre DNS n'est pas bien configuré, peut prendre du temps à expirer. Cela peut également être vu lorsque SSH est connecté à la machine - il faut beaucoup de temps pour proposer une invite.
Affaire SELinux
Si la même commande Sudo est lente uniquement dans un démon et rapide sur la ligne de commande, alors elle est causée par SELinux le plus probablement. (SELinux = NSA Module de noyau Linux à sécurité renforcée, activé dans Fedora par défaut.)
Un cas typique est un serveur http et un script spécial pour la gestion du serveur, limité dans sudoers:
Apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command
Il est typique dans ce cas que rien sur SELinux ne soit signalé dans le journal d'audit ausearch -m avc -ts today, mais le script va vite si nous désactivons temporairement l'application par setenforce 0. (puis réactiver 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): Échec de 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é interrompue.
... Sudo [...]: pam_unix (Sudo: session): session ouverte pour l'utilisateur root par (uid = 0)
La journalisation de tous les messages SElinux "dont-audit" silencieux peut être activée par semodule -DB et désactivé à nouveau par semodule -B.
(J'espère que j'écrirai bientôt un module de politique SELinux pour ce cas ici ou une méthode de cette réponse pourra être utilisée.)
Pour moi, c'était krb5-user/config/locales en cours d'installation. J'ai remarqué cela en examinant /var/log/auth.log. L'utilisation d'apt-get remove pour désinstaller ces packages l'a corrigé. Ne supprimez pas ces packages si vous êtes sur un ordinateur nécessitant des kerberos (pam_krb5) évidemment.
Vérifiez votre fichier/etc/hosts et assurez-vous que vous disposez d'une entrée pour 127.0.0.1
( source )
Après avoir résolu tous les problèmes d'hôte, assurez-vous d'effacer tout cache DNS incorrect si vous exécutez une application de mise en cache DNS comme nscd:
/etc/init.d/nscd force-reload
En regardant l'exemple de fichier sudoers que j'ai, je pense qu'il est censé y avoir un espace après le NOPASSWD: bit.
On dirait que vous avez une sorte de délai d'attente dans votre chaîne d'authentification. Vérifiez comment Sudo essaie de s'authentifier et surveillez les goulots d'étranglement.
Cas Systemd
Pour moi, mon système était à court de mémoire et de nombreux processus se sont écrasés. Mon système est basé sur systemd et quelque chose s'est écrasé. J'ai du mal à 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 résolu mon problème, mais pour moi, c'était juste un panda. Vous devez toujours savoir pourquoi vous avez manqué de mémoire/planté.
Utilisez-vous LDAP pour l'authentification?
Si c'est le cas, vous souhaiterez probablement utiliser la stratégie de liaison douce. Dans /etc/ldap/ldap.conf (ou /etc/ldap.conf):
bind_policy soft