securityd utilisant 100% CPU et polluant system.log

11

Depuis que je suis passé à Mavericks, j'ai souvent les processus suivants utilisant la pleine puissance du processeur:

securityd
syslogd
kernel_task

Je suppose qu'il securitydcontient un bug, car il pollue /var/log/system.logavec des milliers de messages par seconde, et le système ne peut pas suivre.

Voici un exemple de messages que je reçois:

Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 44365 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 26642 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 44365 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 26642 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---

Je crois que c'est un problème critique, car cela rend Mac OS X extrêmement lent et ne répond pas.

Tuer securityidn'aide pas. Le processus est recréé et continue de polluer syslogd.

Si je redémarre l'ensemble du système, tout semble correct pendant un certain temps, avant que le même problème ne se reproduise. Je n'ai pas encore compris ce qui déclenche ce problème.

mavericks

— alexpirine
source

Si vous n'obtenez pas une bonne réponse, vous pouvez exécuter sudo sysdiagnose securitydet déposer un rapport de bogue et éventuellement obtenir l'aide d'Apple pour corriger le bogue ou résoudre la cause.

— bmike

1

Vous pouvez également essayer d'enlever temporairement /System/Library/LaunchDaemons/com.apple.securityd.plistou /usr/sbin/securitydou faire une mise à niveau d' installation de Mac OS X à partir de la partition de récupération .

— Lri

J'ai également eu ce problème d'échec de l'assertion securityd avec 10.9. Je ne sais pas encore quel est le problème, mais j'ai redémarré en mode sans échec et désinstalle divers packages tiers (antivirus, ...) avec des extensions de noyau identifiées par EtreCheck . Je soupçonne que l'un d'eux est le problème, mais comme il est un peu intermittent, je vais attendre encore un peu avant de prétendre l'avoir résolu.

— scott

3

Dans mon cas, le processus haywire securityd a été provoqué par l'application de bureau GitHub - lors de la validation, des problèmes de réseau ont provoqué une erreur dans la poignée de main ssh. Les commits suivants se sont bien passés. L'application GitHub a été laissée ouverte, securityd chauffait mon processeur. Quitter l'application GitHub a résolu le problème - mettant probablement fin à quelque chose dans securityd. Donc, je suppose que securityd a un problème de boucle infinie pendant les opérations de cryptage, peut-être juste avec ssh et des poignées de main.

Vérifiez donc si et comment votre flux de travail quotidien peut déclencher securityd (connexion au serveur? Github?) Et isoler le problème.

— f055
source

L'application Github était aussi la coupable pour moi.

— Teetotum

1

Vous pouvez temporairement résoudre le problème en redémarrant SecurityAgent à l'aide de la commande de terminal suivante:

sudo killall SecurityAgent

Cela a fonctionné à chaque fois pour moi. J'étudie toujours la cause profonde.

Pour autant que je sache, cela a été déclenché par le passage à un autre compte d'utilisateur où j'avais dû réinitialiser le mot de passe car j'avais oublié le mot de passe d'origine. Cela a provoqué plusieurs échecs de trousseau (mot de passe original requis pour déverrouiller le trousseau) et j'ai reçu une «boucle sans fin» d'invites du type «Apple Messages Agent veut utiliser l'élément« connexion »de votre trousseau ..»

— JBRWilkinson
source

J'ai également plusieurs invites concernant mon mot de passe après une connexion (2, 3, peut-être 4 de temps en temps).

— alexpirine

Tuer SecurityAgent semble également avoir fonctionné pour moi. Merci! Mais j'aimerais aussi comprendre la cause profonde. Je viens rempli bug # 15924434 à bugreport.apple.com avec la sortie de sysdiagnose securityd.

— alexpirine

1

Le dépannage de la cause réelle peut être problématique car XPC est un protocole de communication inter-processus générique et ne se charge qu'à la demande. Le logiciel Apple utilise ce sous-système comme tout programme tiers - il pourrait donc s'agir de la faute d'Apple ou de quelque chose que vous exécutez et le principal problème est que vous n'avez pas de moyen facile de savoir quel programme est à l'origine de la lourde charge de journalisation. (et peut-être une lourde charge de travail légitime ainsi qu'une simple journalisation).

Je conviens que toute journalisation de diagnostic qui est si rapide et incontrôlable qu'elle affecte soit la consommation d'énergie de l'ordinateur soit les performances de l'ordinateur de manière notable doit être considérée comme un défaut.

La façon la plus productive de résoudre ce problème est en fait de documenter le problème et de le signaler comme un bug à Apple.

Mavericks a fait un travail remarquable en exposant à la fois les outils de diagnostic et la consommation d'énergie au fil du temps de tous les processus à l'utilisateur final intéressé.

Ouvrez Energy Saver, sélectionnez Energy et triez par Impact énergétique moyen - prenez une photo de la fenêtre dans laquelle il traite les journaux d'utilisation du dernier jour.
Sélectionnez la vue CPU, recherchez-la securityd, sélectionnez-la dans la liste des tâches actives puis "Exécuter les diagnostics du système ..." soit dans le menu Affichage, soit dans l'engrenage de la barre d'outils.
Envoyez à la fois l'image et le rapport de diagnostic compressé à Apple à l' adresse https://developer.apple.com/bug-reporting/

Vous aurez besoin d'un AppleID associé à une sorte de compte de développeur, vous pouvez donc vous inscrire gratuitement en tant que développeur Safari si vous ne possédez pas déjà un compte qui est activé pour signaler des bogues spécifiques à Apple.

— bmike
source

De plus - si quelqu'un a des étapes pour reproduire ce bogue dans securityd - je déposerai volontiers un rapport de bogue en double et ferai le travail pour le soumettre à Apple, mais je n'ai pas eu un seul journal système sur un volume de ces messages sur 10.9 pour plusieurs mois.

— bmike

merci pour les instructions, j'ai généré un rapport, mais votre lien où je pourrais envoyer le rapport ne fonctionne pas. Il redirige vers un ensemble de données JSON, indiquant "Votre session a expiré en raison de l'inactivité".

— alexpirine

On dirait que l'URL a changé, je vais créer un lien vers l'article qui explique comment utiliser l'outil à la place. Il a un lien de connexion et d'inscription sur la gauche de la page (actuellement).

— bmike

Cela fonctionne enfin - merci - c'était peut-être un bug temporaire sur les serveurs d'Apple. J'ai rempli un bogue avec la sortie de sysdiagnose securityd.

— alexpirine

0

Je vois le même problème exact pour la deuxième fois consécutive en une semaine avec exactement les mêmes messages dans la console.

Pour moi, le redémarrage résout généralement le problème (la première fois que je devais forcer l'arrêt car la machine ne répondait pas). Et comme vous, je n'ai pas encore trouvé le déclencheur qui déclenche les messages.

Le moniteur d'activité n'est pas le coupable, je suis généralement alerté par le fan qui devient fou, alors je démarre le moniteur d'activité juste pour voir à la fois syslogd et securityd en utilisant environ 90% du CPU.

— Pierrot
source

Le déclencheur pourrait-il ouvrir le moniteur d'activité et lui demander de représenter graphiquement les modèles historiques de consommation d'énergie? Je vois le pic d'utilisation du processeur lorsque je fais cela, mais apparemment, mes journaux du jour ou des deux derniers ne sont pas corrompus d'une manière qui provoque le flot de messages de la console.

— bmike

@bmike no. Il semble que rien de spécial ne le déclenche. Mon sentiment est que cela se produit lorsque l'ordinateur est allumé pendant un certain temps et lorsque je me connecte après un économiseur d'écran / une activité suspendue. De plus, lorsque je me connecte, j'ai deux ou trois autres invites concernant mon mot de passe, cela peut être lié à ce problème.

— alexpirine

J'ai rempli un rapport de bug sur bugreport.apple.com et il a été fermé aujourd'hui, disant qu'il s'agit d'un doublon du bug # 15090630 (qui est toujours ouvert). Existe-t-il un moyen de voir ce rapport de bogue?

— alexpirine

0

Je pense que cela peut être un bug beaucoup plus ancien que Mavericks. Je ne suis pas sûr d'avoir le même problème que vous parce que je n'ai jamais vérifié syslog, mais j'ai securitydmangé du CPU et de la RAM. J'ai utilisé une ancienne solution de 2007 (pour Leopard?).

tldr:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

puis redémarrez. N'hésitez pas à supprimer l'ancien fichier par la suite, car OS X en crée automatiquement un nouveau.

— Owen Masback
source

Bonjour, veuillez noter que ce bogue est lié à la pollution des journaux système. Si securityd ne produisait pas autant de sortie de débogage, le système ne fonctionnerait pas à 100% CPU. Apparemment, les développeurs Apple sont conscients de ce bogue, car je l'ai signalé et il a été marqué comme doublon. Donc je suppose que nous devons attendre…

— alexpirine

0

J'ai créé une machine virtuelle à l'aide de virtualBox et ce problème est quelque peu récréatif. J'ai créé des éléments de trousseau et lorsque je visite le site Web auquel l'élément de trousseau est destiné, la machine virtuelle se bloque pendant 1 à 2 minutes, puis se libère. Il peut s'agir de git-osxkeychain-helper qui fait que le processus securityd mange tout le processeur.

— jwallis
source

0

Semble avoir quelque chose à voir avec le gestionnaire de trousseaux. J'étais en train de l'avoir et j'ai tué le trousseau et c'est parti.

— bob
source