6

Что-то заполняет мои системные журналы, до такой степени, что console.app будет показывать только последние полчаса каждого файла. Похоже, что-то пытается вырваться из песочницы, но я не совсем уверен, что ... Я получаю МНОГИЕ повторяющиеся сообщения, которые выглядят так:

Feb  3 00:29:57 Brians-mini sandboxd[16]: syslogd(15) deny file-read-data /private/var/log/asl/StoreData
Feb  3 00:29:57 Brians-mini sandboxd[16]: syslogd(15) deny mach-task-name
Feb  3 00:29:57 Brians-mini sandboxd[16]: syslogd(15) deny file-read-data /private/var/log/asl/StoreData
Feb  3 00:29:57 Brians-mini sandboxd[16]: syslogd(15) deny mach-task-name
Feb  3 00:29:59: --- last message repeated 1 time ---
Feb  3 00:29:57 Brians-mini sandboxd[16]: *** process 16 exceeded 500 log message per second limit  -  remaining messages this second discarded ***
Feb  3 00:29:57 Brians-mini sandboxd[16]: syslogd(15) deny mach-task-name
Feb  3 00:30:00: --- last message repeated 499 times ---
Feb  3 00:29:58 Brians-mini sandboxd[16]: *** process 16 exceeded 500 log message per second limit  -  remaining messages this second discarded ***
Feb  3 00:29:58 Brians-mini sandboxd[16]: syslogd(15) deny mach-task-name

Изменить, чтобы добавить:

Монитор активности говорит, что sandboxd занимает 60% процессора, а syslogd - 120%. Теперь я предполагаю, что это процессор PER (я нахожусь на дуэте с ядром 2), но это все еще ужасное количество процессоров для этих двух процессов ...

РЕДАКТИРОВАТЬ: var/log/asl согласно запросу:

drwxr-xr-x  25 root     wheel       850 Jan  6 06:41 ./
drwxr-xr-x  47 root     wheel      1598 Feb  4 15:16 ../
-rw-r-----   1 root     admin     11414 Jan  4 11:49 2010.01.04.U0.G80.asl
-rw-------   1 root     wheel       874 Jan  4 09:41 2010.01.04.U0.asl
-rw-------   1 acordex  wheel     43862 Jan  4 17:53 2010.01.04.U501.asl
-rw-r--r--   1 root     wheel     44614 Jan  4 23:42 2010.01.04.asl
-rw-r-----   1 root     admin  10241494 Jan  5 16:53 2010.01.05.U0.G80.asl
-rw-------   1 acordex  wheel    669585 Jan  5 18:11 2010.01.05.U501.asl
-rw-r--r--   1 root     wheel    772889 Jan  5 23:42 2010.01.05.asl
-rw-r-----   1 root     admin      9731 Jan  6 18:54 2010.01.06.U0.G80.asl
-rw-------   1 acordex  wheel    404532 Jan  6 18:50 2010.01.06.U501.asl
-rw-r--r--   1 root     wheel    838013 Jan  6 18:53 2010.01.06.asl
-rw-r-----   1 root     admin     52896 Sep 24 18:20 BB.2010.09.30.U0.G80.asl
-rw-r--r--   1 root     wheel     50908 Sep 29 10:30 BB.2010.09.30.asl
-rw-r-----   1 root     admin     58875 Oct 30 11:18 BB.2010.10.31.U0.G80.asl
-rw-r--r--   1 root     wheel     46188 Oct 30 17:41 BB.2010.10.31.asl
-rw-r-----   1 root     admin     10322 Nov  5 18:21 BB.2010.11.29.U0.G80.asl
-rw-r--r--   1 root     wheel      2159 Nov  4 17:21 BB.2010.11.29.asl
-rw-r-----   1 root     admin      6586 Nov  9 14:06 BB.2010.11.30.U0.G80.asl
-rw-r--r--   1 root     wheel     23147 Nov 25 16:36 BB.2010.11.30.asl
-rw-r-----   1 root     admin     21686 Dec 16 19:06 BB.2010.12.31.U0.G80.asl
-rw-r--r--   1 root     wheel     36951 Dec 23 18:32 BB.2010.12.31.asl
-rw-r--r--   1 root     wheel      2584 Jan  6 16:49 BB.2011.01.31.asl
-rw-r--r--   1 root     wheel        12 Jan  6 18:54 StoreData
-rw-r--r--   1 root     wheel         8 Jan  6 16:59 SweepStore
|источник

4 ответа4

5

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

Проверьте содержимое /System/Library/LaunchDaemons/com.apple.syslogd.plist (элемент launchd, который контролирует запуск syslogd). У этого должен быть раздел как это:

    <key>ProgramArguments</key>
    <array>
<!--
    Un-comment the following lines to run syslogd with a sandbox profile.
    Sandbox profiles restrict processes from performing unauthorized
    operations; so it may be necessary to update the profile
    (/usr/share/sandbox/syslogd.sb) if any changes are made to the syslog
    configuration (/etc/syslog.conf).
-->
<!--
        <string>/usr/bin/sandbox-exec</string>
        <string>-f</string>
        <string>/usr/share/sandbox/syslogd.sb</string>
-->
        <string>/usr/sbin/syslogd</string>
    </array>

Обратите внимание, что в приведенном выше примере (взятом из моего Mac) закомментирована оболочка песочницы вокруг syslogd. То же самое на вашем Mac? Если нет, повторно добавьте маркеры комментариев и перезапустите syslogd (вы можете сделать это с помощью launchctl , но я бы просто перезагрузил компьютер).

Еще одно замечание: я заглянул в профиль песочницы, /usr/share/sandbox/syslogd.sb , и он (на мой неопытный взгляд) выглядит так, как будто он запрещает mach-task-name мач и доступ к /private/var/log/asl/StoreData - очевидно, Apple не отлаживал (/ обновлял) профиль, чтобы соответствовать тому, что на самом деле нужно syslogd ...

|источник
1

Ну, процесс наполнения - песочница (процесс 16).

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

|источник
1

Две разные мысли:

  1. Попытайтесь определить, есть ли определенный процесс, порожденный sandboxd, который вызывает эти ошибки. Запустите приложение Activity Monitor и выберите «Все процессы, иерархически» в списке выбора в верхней части окна. Найдите sandboxd в списке и посмотрите, есть ли под ним дочерние процессы - дочерние процессы будут иметь отступ.

  2. Упоминание сообщений журнала /private /var /log /asl. Посмотрите справочные страницы для aslmanager и asl.conf (файл конфигурации для aslmanager). В файле конфигурации есть настройка уровня ведения журнала. Возможно, это поднялось до более детального уровня.

|источник
0

Это происходит при загрузке в безопасном режиме?

Это происходит у другого пользователя?

Есть ли какие-либо ссылки в console.log?

Можете ли вы вставить результаты ls -la /private/var/log/asl/ - возможно, что-то там не так.

Вы изменили /System/Library/LaunchDaemons/com.apple.aslmanager.plist или /private/etc/asl.conf

Вы должны увидеть записи за 7 дней в 10.6 в syslog, используя syslog | grep -v sandboxd | grep -v "last message repeated" | tail -n 100 Это покажет вам последние 100 записей без песочницы в ASL. Возможно, это даст вам ключ к пониманию того, что еще происходит.

Если он заполняется настолько быстро, что ASL достигает своего максимального размера очень быстро, вы можете попытаться увеличить размер, до которого база данных ASL может временно увеличиться, с помощью max_store_size в /private/etc/asl.conf Дополнительная информация на странице руководства. Выполнение этого и последующее выполнение команды syslog выше может привести к некоторой полезной информации журнала.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .