Система входит в систему Mac OSX 10.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% CPU, и syslogd поднимает 120%. Теперь, я предполагаю, что это - процессор PER (я нахожусь на Core 2 Duo), Но это - все еще очень много CPU для тех двух процессов...
Править: 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 ответа
Смотрит на меня как, он 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 на самом деле потребности...
Ну, процесс, заполняющий вещи, является sandboxd (обработайте 16).
Относительно того, почему это регистрируется так, мы должны были бы видеть больше его сообщений для понимания проблемы. (Это смотрит от этого крошечного отрывка как некоторая программа, пытается сделать, что-то несанкционированное - получает доступ к указанному файлу - но здесь нет большого количества информации.)
Две различных мысли:
Попытайтесь определить, существует ли конкретный процесс, порожденный sandboxd, который вызывает эти ошибки. Запустите приложение Монитора Действия и выберите "All Processes, Hierarchically" из списка выборки наверху окна. Найдите sandboxd в списке и посмотрите, существуют ли какие-либо дочерние процессы под ним - дочерние процессы будут расположены с отступом.
Сообщения журнала упоминают/private/var/log/asl. Посмотрите на страницы справочника для
aslmanagerиasl.conf(файл конфигурации для aslmanager). Существует установка в файле конфигурации для входа уровня. Возможно, это было ударено к более подробному уровню.
Это происходит, когда Вы загружаетесь в безопасный режим?
Это происходит в другом пользователе?
Есть ли, кто-либо вводит console.log?
Можно ли вставить результаты ls -la /private/var/log/asl/ - возможно, что-то неправильно там.
Вы изменили /System/Library/LaunchDaemons/com.apple.aslmanager.plist или /private/etc/asl.conf
Необходимо смочь видеть, что записи возвращаются 7 дней в 10,6 в системном журнале при помощи syslog | grep -v sandboxd | grep -v "last message repeated" | tail -n 100 Это покажет Вам последние 100 не sandboxd записи в ASL. Возможно, это даст Вам ключ к разгадке относительно того, что еще продолжается.
Если это заполняется настолько быстро, что ASL достигает, это - макс. размер очень быстро, Вы могли попытаться увеличить размер, до которого может вырасти база данных ASL временно с max_store_size в /private/etc/asl.conf Больше информации о странице справочника. Выполнение этого и затем выполнение команды системного журнала выше могут привести к некоторой полезной информации о журнале.