Mac OSX 10.6 中的系统日志

Question 1

在我看来，它syslogd本身就导致了问题 —— 它被沙盒化，远离其数据文件，因此当它试图访问它们时，它会生成一个沙盒错误，该错误会被传递给syslogd，这会触发它再次尝试获取其文件……并且这会以最快的速度重复syslogd进行sandboxd。

/System/Library/LaunchDaemons/com.apple.syslogd.plist检查（控制 syslogd 如何启动的 launchd 项）的内容。它应该有一个类似这样的部分：

    <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实际需要...

Answer

在我看来，它syslogd本身就导致了问题 —— 它被沙盒化，远离其数据文件，因此当它试图访问它们时，它会生成一个沙盒错误，该错误会被传递给syslogd，这会触发它再次尝试获取其文件……并且这会以最快的速度重复syslogd进行sandboxd。

/System/Library/LaunchDaemons/com.apple.syslogd.plist检查（控制 syslogd 如何启动的 launchd 项）的内容。它应该有一个类似这样的部分：

    <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实际需要...

Question 2

嗯，填充内容的进程是 sandboxd（进程 16）。

至于为什么它会记录这么多，我们需要查看更多消息才能了解问题所在。（从这个小片段来看，好像某个程序正在尝试做一些未经授权的事情——访问指定的文件——但这里没有太多信息。）

Answer

嗯，填充内容的进程是 sandboxd（进程 16）。

至于为什么它会记录这么多，我们需要查看更多消息才能了解问题所在。（从这个小片段来看，好像某个程序正在尝试做一些未经授权的事情——访问指定的文件——但这里没有太多信息。）

Question 3

两种不同的想法：

尝试确定是否有由 sandboxd 生成的特定进程导致了这些错误。运行活动监视器应用并从窗口顶部的选择列表中选择“所有进程，按层次结构”。在列表中找到 sandboxd 并查看其下是否有任何子进程 - 子进程将被缩进。
日志消息提到了 /private/var/log/asl。查看手册页aslmanager和asl.conf（aslmanager 的配置文件）。配置文件中有一个日志记录级别的设置。也许这个级别被提升到了更详细的级别。

Answer

两种不同的想法：

尝试确定是否有由 sandboxd 生成的特定进程导致了这些错误。运行活动监视器应用并从窗口顶部的选择列表中选择“所有进程，按层次结构”。在列表中找到 sandboxd 并查看其下是否有任何子进程 - 子进程将被缩进。
日志消息提到了 /private/var/log/asl。查看手册页aslmanager和asl.conf（aslmanager 的配置文件）。配置文件中有一个日志记录级别的设置。也许这个级别被提升到了更详细的级别。

Question 4

当您启动到安全模式时会发生这种情况吗？

其他用户也发生这种情况吗？

console.log 中有什么线索吗？

你能粘贴结果吗ls -la /private/var/log/asl/——也许那里有些不对劲。

您是否修改过/System/Library/LaunchDaemons/com.apple.aslmanager.plist或/private/etc/asl.conf

您应该能够使用 syslog 查看 10.6 中过去 7 天的条目，syslog | grep -v sandboxd | grep -v "last message repeated" | tail -n 100这将向您显示 ASL 中的最后 100 个非沙盒条目。也许这会为您提供有关正在发生的其他事情的线索。

如果 ASL 的容量很快达到上限，你可以尝试使用 max_store_size 临时增加 ASL 数据库的大小， /private/etc/asl.conf更多信息请参见手册页。执行此操作然后运行上面的 syslog 命令可能会产生一些有用的日志信息。

Answer