Да, конечно, эти сообщения получаются при работе SpiderGuard. В том случае, когда следует проверить некоторый файл (а он, к примеру, удаляется в этот момент): 1) SpiderGuard даёт указание drwebd просканировать файл (это минимально нагружающий систему способ) 2) drwebd не может этого сделать (No such file or directory), он не исполнил указание, это ошибка, она в логе 3) для SpiderGuard ошибка drwebd -- это ценный результат, который используется при дальнейшей обработке потенциальной угрозы.
Как я понял, идеальным решением будет не выводить в syslog ошибок сканирования из drwebd.
Скажем так, не выводить в протокол ошибки открытия и чтения, т.е. ошибки типа "read error", "No such file or directory" и, наверное, ещё парочка, которые были иницированны SpiDer Guard-ом.
Насколько приемлем вариант установить syslog priority и facility для всех сообщений drwebd (чтобы перенаправить их куда-то, где бы они не мешали, но были бы доступны при необходимости)?
Честно говоря, мне неизвестны точно параметры производительности подсистемы протоколированния Mac OS X. Однако по опыту других систем (Solaris, Linux) могу сказать, что отключение "priority и facility" не отменяет передачи сообщения между процессами, соответственно, расходов с этим связанных.
Типичная картина загрузки системы для интенсивного возникновения событий (тысячи сообщений в секунду): разрешена priority (есть запись в syslog.conf) - загрузка 98%, priority запрещена (строка в syslog.conf закоментированна) - 70%, нет вызова syslog() - 1 %.
Но это всё рассуждения за уменьшение расходов в идеале. Вероятно при запуске нагрузочных тестов файловых систем тысячи создаваемых/удаляемых файлов в секунду будут легко достижимы, но лично в моей жизни речь будет идти за временные файлы разнообразных компиляторов, а это не более сотен в секунду. Но я возьму эту возможную особенность на заметку (вдруг EFS будем делать).
Однако, замечу, что сообщение вида "/Users/leo/Library/Preferences/com.apple.finder.plist.rlQkrc4" вызвает подозрение о риске большой нагрузки, т.к., как я понимаю, это временные файлы при работе с defaults/plist (аналогом реестра Windows). Которая может быть весьма интенсивной.
