Pourquoi sudo prend-il trop de temps?

13

J'ai récemment mis à jour vers macOS Sierra 10.12.4 Beta (16E144f) et c'est peut-être ce qui cause un sudoretard de 10 minutes, car c'est le changement le plus récent dont je me souvienne depuis que ce problème s'est produit. Je n'ai jamais eu à attendre aussi longtemps pour un programme de base et quelque chose cloche clairement. La commande réussit finalement, mais après avoir attendu trop longtemps.

J'ai utilisé cette question comme référence. Jusqu'à présent, j'ai également essayé d'ajouter mon nom d'hôte à la fin de la 127.0.0.1ligne /etc/hosts. J'ai vérifié /etc/resolv.confet j'avais quelques entrées supplémentaires lorsque j'étais sur un réseau qui avait besoin d'entrées DNS manuelles, mais je les ai supprimées et il n'y a pas de différence. J'ai utilisé la networksetup -setdnsserverscommande pour restaurer les valeurs d'origine. Internet fonctionne toujours bien mais reste très lent sudo.

J'ai essayé la logger 'test'commande en pensant qu'elle écrirait /var/log/system.log, mais il semble qu'elle ait totalement supprimé ce fichier bien qu'il ait bientôt été refait.

J'espérais utiliser la stracecommande pour voir ce qui se passait pendant l' sudoexécution, mais cette commande n'est pas disponible sur OS X. Quelqu'un a-t-il déjà rencontré ce problème sur ce système d'exploitation?

/var/log/system.log contient les messages suivants qui peuvent être pertinents. Encore une fois, la commande réussit finalement comme d'habitude:

Feb  1 00:07:39 mycomputer com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Feb  1 00:07:56 mycomputer com.apple.xpc.launchd[1] (com.apple.quicklook[2355]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
Feb  1 00:08:16 mycomputer System Preferences[1886]: I can not do what i want
Feb  1 00:11:23 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2335]): Service exited with abnormal code: 70
Feb  1 00:12:07 mycomputer syslogd[54]: ASL Sender Statistics
Feb  1 00:16:35 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2395]): Service exited with abnormal code: 70

Toute aide serait appréciée.

terminal sierra permission hang sudo Spencer Williams
la source
Peu importe la commande que vous exécutez via sudo? Comment les horodatages du journal sont-ils liés à votre action d'exécution de sudo et sur sudo qui le traverse? Je vois opendirectoryd là-dedans, travaillez-vous avec un compte local ou un compte réseau? Que se passe-t-il si vous changez d'utilisateur (ou si vous en créez un localement), est-ce que sudo est également lent?
nohillside
J'utilise la même version bêta et sudo est rapide comme toujours.
nohillside
1
@patrix Ah d'accord. Oui, ça pourrait très bien être autre chose. Oui, cela arrive quelle que soit la commande que j'utilise avec sudo, le délai est constant. Fondamentalement, la commande commence autour de cette ligne de journal com.apple.quicklooket se termine finalement à la fin, donc dans cet exemple, il a fallu environ 8 minutes avec tous ces messages entre les deux. Le message opendirectoryd semble se produire chaque fois qu'il s'exécute finalement sudo lsdans mon répertoire personnel local. Pour le moment, je ne travaille qu'avec des dossiers locaux. Je n'ai qu'un seul utilisateur sur cet ordinateur bien que je puisse voir ce qui se passe avec un nouveau compte ...
Spencer Williams
@patrix Je viens de créer un autre utilisateur avec des privilèges d'administrateur. Malheureusement, ce compte rencontre le même problème.
Spencer Williams

Réponses:

11

La réponse d'ErikMH m'a donné l'idée d'essayer d'abord de restaurer le fichier sudoers, sans restaurer / mettre à niveau tout mon système à nouveau. Bref:

  1. Exécutez ceci pour obtenir un shell racine: sudo -s
  2. Faites une copie de /private/etc/sudoers
  3. Courir: cp /private/etc/sudoers\~orig /private/etc/sudoers
  4. Corrigez les autorisations en exécutant: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
  5. Déplacez tous les fichiers à /private/etc/sudoers.d/partir de là
  6. Tester sudodans un autre terminal
  7. N'oubliez pas de quitter ce shell pour éviter d'exécuter par inadvertance des commandes en tant que root lorsque vous ne voulez pas

Maintenant, la course sudodevrait fonctionner à nouveau.

L'étape suivante consiste à vérifier les différences entre l'ancien fichier sudoers (que vous avez copié à l'étape 2) et le fichier actuel et à ajouter ces modifications étape par étape à /private/etc/sudoersou /private/etc/sudoers.d/, chaque fois que vous exécutez une commande à l'aide de sudopour vérifier si la modification le casse.

Dans mon cas, j'avais spécifié un groupe inexistant dans le fichier sudoers. La correction de ce problème a résolu mon problème.

Cedric Dubois
la source
travaillé sur macOS 10.13!
Nisba
A également fonctionné pour moi (OSX 10.13). Également eu le même problème - groupe inexistant dans le fichier sudoer.
Petr Cibulka
Hmm ... Je ne me souviens pas avoir changé le fichier sudoers sur la machine où j'ai eu ce problème, mais j'aurais aimé avoir essayé ce que vous proposez au lieu de restaurer mon système.
Spencer Williams
Je suis allé de l'avant et j'ai accepté votre réponse car il semble que les gens confirment que cela aide, et je souhaite certainement avoir essayé cela en premier, et je ne recommande généralement pas de restaurer votre système entier.
Spencer Williams
2

Cela peut se produire lors de la mise à niveau vers 10.12.4 si vous avez déjà modifié le fichier / private / etc / sudoers.

La solution la plus simple est:

  1. Revenez à une version précédente du système (vous clonez toujours votre système avant la mise à jour, non?)
  2. Supprimer / private / etc / sudoers
  3. Copiez / private / etc / sudoers ~ orig vers sudoers
  4. Réinitialiser la propriété des sudoers sur system / root - lecture seule
  5. Mettre à niveau le système vers 10.12.4
ErikMH
la source
"Cela peut se produire lors de la mise à niveau vers 10.12.4 si vous avez déjà modifié le fichier / private / etc / sudoers." Savons-nous ce qui en est réellement la cause?
Wowfunhappy
1

Je souhaite que j'aurais pu trouver la cause réelle de cela, mais je n'ai pu résoudre le problème qu'après avoir restauré le logiciel système. J'étais auparavant sur la bêta publique de macOS Sierra mais maintenant je suis sur la principale.

Je charge lentement tous mes programmes et je noterai si je ressens de sudonouveau un retard .

Spencer Williams
la source
0

J'avais un fichier dans /etc/sudoers.d/lequel j'ai supprimé. Voila - sudoest encore rapide.

vidstige
la source