securityd использует 100% CPU и загрязняет system.log

Так как я обновился до Mavericks, у меня часто есть следующие процессы, использующие полную мощность процессора:

• securityd
• syslogd
• kernel_task

Я думаю, securitydсодержит ошибку, потому что она загрязняет /var/log/system.logтысячи сообщений в секунду, и система не может следить.

Вот пример сообщений, которые я получаю:

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 ---

Я считаю, что это критическая проблема, так как она делает Mac OS X чрезвычайно медленной и не отвечает.

Убийство securityidне помогает. Процесс воссоздается и продолжает загрязнять syslogd.

Если я перезагружаю всю систему, некоторое время все кажется нормальным, прежде чем та же проблема повторяется. Я еще не понял, что вызывает эту проблему.

В моем случае процесс обеспечения безопасности haywire был вызван приложением GitHub для настольных компьютеров - во время фиксации проблемы с сетью приводили к ошибке в ssh handshake. Последующие коммиты прошли нормально. Приложение GitHub осталось открытым, securityd нагревал мой процессор. Выход из приложения GitHub устранил проблему - возможно, что-то завершилось в securityd. Таким образом, я предполагаю, что у securityd есть некоторая проблема с бесконечным циклом во время операций шифрования, возможно, только с помощью ssh и рукопожатий.

Итак, проверьте, может ли и как ваш ежедневный рабочий процесс вызывать securityd (вход на сервер «github»), и выявить проблему.

Вы можете временно устранить проблему, перезапустив SecurityAgent с помощью следующей команды терминала:

sudo killall SecurityAgent

Это работало каждый раз для меня. Я все еще расследую основную причину.

Насколько я могу судить, это было вызвано переключением на другую учетную запись пользователя, где мне пришлось сбросить пароль, поскольку я забыл исходный пароль. Это вызвало множество сбоев связки ключей (исходный пароль требуется для разблокировки связки ключей), и я получил «бесконечный цикл» подсказок в духе «Агент сообщений Apple хочет использовать элемент« Логин »из цепочки для ключей…».

Устранение неполадок с реальной причиной может быть проблематичным, поскольку XPC является универсальным протоколом межпроцессного взаимодействия и загружается только по требованию. Программное обеспечение Apple использует эту подсистему так же, как и любую стороннюю программу - так что это может быть ошибка Apple, или это может быть то, что вы запускаете, и главная проблема в том, что у вас нет простого способа узнать, какая программа вызывает большую нагрузку при ведении журнала. (и, возможно, большая допустимая рабочая нагрузка, а также просто регистрация).

Я согласен с тем, что любая диагностическая регистрация, настолько быстрая и неконтролируемая, что заметно влияет на энергопотребление компьютера или производительность компьютера, должна рассматриваться как ошибка.

Наиболее эффективный способ решения этой проблемы - документировать проблему и сообщать об этом Apple как об ошибке.

Маверикс проделал звездную работу, предоставляя заинтересованным конечным пользователям как инструменты диагностики, так и потребление энергии во времени для всех процессов.

• Откройте Energy Saver, выберите Energy и отсортируйте по Avg Energy Impact - сделайте снимок окна, в котором он обрабатывает журналы использования за последний день.
• Выберите представление CPU, выполните поиск securityd, выберите его в списке активных задач, а затем «Run System Diagnostics ...» либо в меню View, либо в шестерне на панели инструментов.
• Отправьте изображение и сжатый отчет о диагностике в Apple по адресу https://developer.apple.com/bug-reporting/.

Вам понадобится AppleID, связанный с какой-либо учетной записью разработчика, поэтому вы можете бесплатно зарегистрироваться в качестве разработчика Safari, если у вас еще нет учетной записи, которая позволяет сообщать об определенных ошибках в Apple.

Я вижу ту же самую проблему во второй раз подряд в течение недели с точно такими же сообщениями в консоли.

Для меня перезагрузка обычно решает проблему (в первый раз мне пришлось принудительно завершить работу, поскольку машина не отвечала). И, как и вы, мне еще предстоит найти триггер, который запускает сообщения.

Монитор активности не является виновником, меня обычно предупреждает сумасшедший фанат, поэтому я запускаю монитор активности, просто чтобы увидеть syslogd и securityd, использующие около 90% процессорного времени.

Я думаю, что это может быть ошибка намного старше, чем Маверикс. Я не уверен, что у меня возникла та же проблема, что и у вас, потому что я никогда не проверял свои syslog, но у меня все-таки было достаточно securitydресурсов процессора и оперативной памяти. Я использовал старое решение с 2007 года (для Leopard?).

tldr:

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

затем перезагрузите. Не стесняйтесь удалять старый файл впоследствии, так как OS X автоматически создает новый.

Я создал виртуальную машину, используя virtualBox, и эту проблему можно воссоздать. Я создал несколько элементов цепочки для ключей, и когда я захожу на веб-сайт, для которого предназначен элемент цепочки для ключей, виртуальная машина зависает в течение 1-2 минут, а затем освобождается. Это может быть git-osxkeychain-helper, заставляющий процесс securityd съесть весь процессор.

Кажется, что-то связано с менеджером цепочки для ключей. Я просто получил это и убил брелок, и он ушел.