DTrace

Вопрос: как получить список всех лог-файлов, использующихся в Solaris?
Естественно, большинство из них известно, однако многие программы могут писать логи туда, куда вы укажете, а на большом сервере этих программ может быть достаточно, чтобы вы позабыли директории журналов. Тем не менее, можно привести некоторые отправные точки для поиска лог-файлов:
1. Файл /etc/syslog.conf содержит имена лог-файлов, которые записываются syslog-ом.
2. Директория /var/svc/log - стандартное расположение логов SMF.
3. Файлы в /etc/default, определяющие журналы для служб, не использующих syslog. Например /var/adm/sulog.

Вернемся к разговору о недокументированных трюках с DTrace, касающихся ssh, о чем мы уже писали. Тогда мы привели пример скрипта, перехватывающего пароли исходящих ssh-коннектов. После этого возможно, кому-то показалась смешным возможность с помощью DTrace получить логины и пароли для ВХОДЯЩИХ ssh-соединений. Мол, с исходящими-то ладно, DTrace просто перехватывает локальный ввод, но со входящими такого не получится, там все закодировано и ssh-программисты не зря свой хлеб едят. А вот системный администратор Manuel Burki из Цюриха так не считает и в который раз заставляет убедиться в неограниченных возможностях DTrace.

Вышедший недавно релиз Sun Studio Express содержит интереснейший модуль D-Light для анализа приложений посредством DTrace. Проект еще юн и некоторые заявленные опции отсутствуют, но открывающиеся при использовании этого плагина возможности впечатляют. Запустив студию и выбрав Tools->D-Light Tool, в развернувшемся окне модуля выбираем Instruments - тут нам доступны Clock profiler, File System Activity, Read Write Monitor и инструменты для Java. Выбираем первые два, кликаем по Select Target и выбираем предложенное первым для примера архивирование tar'ом /usr/include.

Часто администратору Solaris или программисту приходится выяснять причины падения того или иного приложения - это может быть стандартная системная или новая, только что скомпилированная и нуждающаяся в отладке программа. Все усложняется, если речь идет о многопользовательской системе, где запущено множество приложений и очень нелегко отследить причины падения сразу нескольких программ.
Ранее основным способом анализа упавшей программы было исследование core или coredump, что в принципе одно и тоже. Однако этот способ имеет свои недостатки: проблемы с безопасностью - core может содержать данные, которые пользователю знать нельзя; часто огромный размер, из-за чего найти необходимую информацию довольно затруднительно, возможно переполнение диска и послать такой файл для анализа технической поддержке просто нереально.
Можно создавать специальные встраиваемые библиотеки c обработчиками сигналов SIGBUS и SIGSEGV, однако для многопользовательской системы это плохое решение.