13. Отчет о состоянии службы и ее журнал

При работе с системами, использующими systemd, одной из наиболее важных и часто используемых команд является systemctl status. Она выводит отчет о состоянии службы (или другого юнита). В таком отчете приводится статус службы (работает она или нет), список ее процессов и другая полезная информация.
В Fedora 17 мы ввели Journal, новую реализацию системного журнала, обеспечивающую структурированное, индексированное и надежное журналирование, при сохранении совместимости с классическими реализациями syslog. Собственно, мы начали работу над Journal только потому, что хотели добавить одну, казалось бы, простую, возможность: включить в вывод systemctl status последние 10 сообщений, поступивших от службы в системный журнал. Но на практике оказалось, что в рамках классических механизмов syslog, реализация этой возможности чрезвычайно сложна и малоэффективна. С другой стороны, сообщения службы в системный журнал несут очень важную информацию о ее состоянии, и такая возможность действительно была бы очень полезной, особенно при диагностике нештатных ситуаций.
Итак, мы интегрировали Journal в systemd, и научили systemctl работать с ним. Результат выглядит примерно так:

Очевидно, это отчет о состоянии всеми любимого демона mDNS/DNS-SD, причем после списка процессов, как мы и обещали, приведены сообщения этого демона в системный журнал. Миссия выполнена!
Команда systemctl status поддерживает ряд опций, позволяющих настроить вывод информации в соответствии с вашими пожеланиями. Отметим две наиболее интересные из них: ключ -f позволяет в реальном времени отслеживать обновление сведений (по аналогии с tail -f), а ключ -n задает количество выводимых журнальных записей (как нетрудно догадаться, по аналогии с tail -n).
Журнальные записи собираются из трех различных источников. Во-первых, это сообщения службы в системный журнал, отправленные через функцию libc syslog(). Во-вторых, это сообщения, отправленные через штатный API системы Journal. И наконец, это весь текст, выводимый демоном в STDOUT и STDERR. Проще говоря, все, что демон считает нужным сказать администратору, собирается, упорядочивается и отображается в одинаковом формате.
Добавленная нами возможность, при всей своей простоте, может оказаться чрезвычайно полезной практически любому администратору. По-хорошему, ее стоило реализовать еще 15 лет назад.

Содержание
Вперед - Самодокументированный процесс загрузки
Назад - К вопросу о безопасности