Astra linux журнал ошибок - Решение и исправление самых разных ошибок на TopOshibok.ru

Обновления Astra Linux, выпущенные после очередного обновления 1.5, используют систему управления службами systemd (подробнее см. Systemd). В состав компонент systemd, предоставляемых при установке ОС входят:

systemd — системная служба управления службами;
systemctl – инструмент командной строки для управления службами;
systemd-analyze — инструмент командной строки для получения статистики работы служб;
journald – системная служба ведения журналов служб;
journalctl — инструмент командной строки для анализа журналов служб.

Инструмент journalctl для анализа журналов системных служб

Общая команда для просмотра журналов:

sudo journalctl

Команды выводит все записи из всех журналов начиная с момента последней загрузки ОС. Записи выводятся в порядке регистрации. При просмотре можно использовать клавиши PageUp и PageDown для поэкранного листания, Пробел — для поэкранного последовательного просмотра, Enter — для построчного последовательного просмотра, Q — для выхода. Отметки времени регистрации событий по умолчанию отображаются в локальном времени. Для отображения отметок времени в формате UTC (см. Службы синхронизации времени в Astra Linux) можно использовать опцию —utc:

sudo journalctl —utc

Полезной может быть также опция short-precise отображения времени с точностью до микросекунд:

sudo journalctl —utc -o short-precise

формат:

мар 18 14:28:46.171881 se10704 kernel:

или опция short-iso-precise (доступна начиная с очередного обновления x.7):

sudo journalctl —utc -o short-iso-precise

формат:

2023-03-18T14:28:46.171893+0300 se10704 kernel:

Для фильтрации сообщений по критичности можно использовать опцию -p с указанием уровня критичности. Для обозначения критичности используются следующие значения:

0 — emergency — неработоспособность системы;
1 — alerts — предупреждения, требующие немедленного вмешательства;
2 — critical — критическое состояние;
3 — errors — ошибки;
4 — warning — предупреждения;
5 — notice — уведомления;
6 — info — информационные сообщения;
7 — debug — отладочные сообщения.

При указании уровня критичности выводятся все сообщения с указанным и меньшим уровнем. Например если указать значение -p 3, то будут показаны все сообщения с уровнями 3, 2, 1 и 0 (т.е. все сообщения об ошибках).

Источники данных для службы journalctl

Служба journald консолидирует данные из следующих источников:

сокет /run/systemd/journal/stdout – данные, поступающие от служб systemd;
устройство /dev/kmsg — журнал ядра;
устройство /dev/log (/run/systemd/joural/dev-log) — данные приложений, поступающие через службу syslog.

Сохранение журналов после перезагрузок

При настройках, заданных по умолчанию служба journald перезаписывает журналы при каждой перезагрузке. Соответственно, вызов инструмента journalctl выведет журнал начиная с момента последней загрузки системы. Для сохранения журналов на постоянной основе (после перезагрузки) следует создать каталог /var/log/journal/, в котором и будут на постоянной основе сохраняться журналы. Для управления постоянным сохранением журналов используется параметр Storage в файле /etc/systemd/journald.conf. По умолчанию этот параметр не задан (имеет значение Auto). При этом каталог постоянного хранения журналов /var/log/journal/:

используется, если он существует;
не создается автоматически, и если этого каталога не существует, то журнал будет записываться в /run/log/journal без сохранения между перезагрузками.

Каталог будет /var/log/journal/ создаваться автоматически если значение параметра Storage изменить на persistent и перезапустить systemd-journald.service или перезагрузить ОС. Подробнее см. man journald.conf.

Проверить наличие сохраненных журналов можно командой:

sudo journalctl —list-boots

Пример вывода команды:

-1 98b893e51c0a43249b8b6e824266fc1c Tue 2023-02-28 07:46:21 MSK—Tue 2023-02-28 15:22:02 MSK 
 0 cdd48e77de394ebca4df162359bfb412 Tue 2023-02-28 15:22:17 MSK—Tue 2023-02-28 15:41:34 MSK

В примере вывода первое поле представляет собой номер журнала, второе поле — идентификатор загрузки. Далее предоставлен диапазон времени, в течение которого выполнялась запись в журнал. Эти значения можно использовать при выборе журнала для просмотра. Например, просмотреть журнал последней загрузки ОС, можно командой:

sudo journalctl -b 0

Для просмотра журнала предпоследней загрузки:

sudo journalctl -b -1

Фильтрация сообщений

Просмотр сообщений определенной загрузки

Для выбора загрузки для фильтрации сообщений можно использовать опцию -b с указанием номера журнала. Например, просмотреть журнал последней загрузки ОС, можно командой:

sudo journalctl -b 0

Для просмотра журнала предыдущей загрузки:

sudo journalctl -b -1

Просмотр сообщений за определенный период времени

Для задания периодов времени для фильтрации событий при просмотре можно использовать опции —snce (с какого времени) и —until (до какого времени) в сочетании с лексемами “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас). Например:

sudo journalctl —since yesterday

или

sudo journalctl —since «2020-12-17» —until «2020-12-18 10:00:00»

Фильтрация сообщений ядра

Чтобы отдельно просмотреть сообщения ядра используется ключом -k:

sudo journalctl -k

Фильтрация сообщений определенных служб и приложений

Для фильтрации сообщений отдельных служб можно использовать опцию -u. Например, для просмотра сообщений службы NetworkManager можно использовать команду:

sudo journalctl -u NetworkManager.service

Также можно отфильтровать сообщения приложения, указав его исполняемый файл. Например, для менеджера дисплеев fly-dm:

sudo journalctl /usr/bin/fly-dm

или указав конкретный идентификатор процесса:

sudo journalctl _PID=1

Дополнительные опции просмотра

Следить за появлением новых сообщений:

sudo journalctl -f

Показать только последние записи:

sudo journalctl -e

По умолчанию journalctl отсекает части выводимых строк, не вписывающиеся в экран по ширине. Управление этой возможностью производится значением переменной окружения SYSTEMD_LESS, определяющей опции программы less (программа постраничного просмотра, используемая по умолчанию). По умолчанию переменная имеет значение FRSXMK. Опция S отвечает за перенос строк, длина которых превышает ширину экрана терминала. Если опцию S исключить, то строки не будут обрезаться и прочесть их содержимое можно с помощью клавиш «стрелка влево» и «стрелка вправо». Пример команды:

sudo SYSTEMD_LESS=FRXMK journalctl

Ограничение размера журнала

Если журналы сохраняются после перезагрузки, то по умолчанию размер журналов ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства. Максимальный объем журнала можно задать явно в параметре SystemMaxUse в файле /etc/systemd/journald.conf.

Удаление журналов

Удалить файлы журналов можно вручную или использовать journalctl. Например:
Удалить журналы, оставив только последние 100 Мб:

sudo journalctl —vacuum-size=100M

Удалить журналы, оставив журналы только за последние 7 дней:

sudo journalctl —vacuum-time=7d

Источник

В Astra Linux Special Edition очередное обновление x.7 рекомендована к применению служба ведения журналов syslog-ng. В более ранних очередных обновлениях Astra Linux по умолчанию используется служба rsyslog. Служба syslog-ng:

устанавливается по умолчанию при установке оперативных обновлений Astra Linux x.7;
при установке замещает собой службу rsyslog. Служба rsyslog при этом полностью удаляется.

Дальнейшее использование службы rsyslog не соответствует поддерживаемым сценариям эксплуатации. Служба rsyslog более не поддерживается в составе основного репозитория Astra Linux Special Edition (доступна в составе расширенного репозитория). В находящихся в эксплуатации системах службу rsyslog необходимо заменить на службу syslog-ng.

Службы управления журналами

syslog-ng — служба управления журналами syslog-ng по умолчанию используется в Astra Linux Special Edition x.7, доступна в репозиториях более ранних очередных обновлений;
rsyslog — служба управления журналами rsyslog по умолчанию используется в Astra Linux Common Edition и Astra Linux Special Edition ранее очередного обновления x.7, доступна в основном репозитории Astra Linux Special Edition x.7;
syslog (sysklogd) — служба управления журналами syslog в настоящее время в Astra Linux не используется;
logrotate — служба архивирования и очистки (ротации) журналов.

Основные возможности служб:

Получение и передача сообщение по сетевым протоколам TCP/UDP/… с возможностью настройки IP-портов и IP-адресов;
Загрузка внешних модулей;
Фильтрация и перенаправление сообщений по имени программы, источнику, номеру процесса и т.д.;
Удаление ненужных сообщений;

Служба syslog-ng

Расположение файлов конфигурации

основной файл: /etc/syslog-ng/syslog-ng.conf;
дополнительные файлы .conf в каталоге /etc/syslog-ng/conf.d.

Базовые принципы функционирования

Служба syslog-ng получает системные сообщения из указанных источников и перенаправляет их в указанные приемники. Источниками могут быть файлы, удаленные хосты, системные сокеты и другие источники. Источники и приемники являются независимыми объектами и соединяются путями передачи (далее — путь). Путь состоит из одного или нескольких источников и одного или нескольких приемников. Дополнительно определение пути может содержать:

фильтры — правила, применяемые для селекции сообщений;
анализаторы (parsers) — правила для анализа и разбора сообщений;
модификаторы (rewriting rules) — правила для модификации сообщений.

Базовые принципы конфигурации

Конфигурационный файл состоит из определений объектов. Базовый синтаксис определения объекта:

<тип_объекта> <идентификатор_объекта> { <параметр>(<опция> ..., ...) ...; ... };

где:

тип объекта — один из типов:
- source — источник;
- destination — приемник;
- log — путь;
- filter — фильтр;
- parser — анализатор;
- rewrite rule — модификатор;
- template — шаблон;
- option — глобальные опции.
Идентификатор объекта — уникальное имя, определяющее объект. Имена регистр-зависимые. Имена, совпадающие с зарезервированными словами должны заключаться в кавычки. Рекомендуется использовать имена с префиксами, указывающими на тип объекта, например, префикс «s_» для источников, префикс «d_» для приемников и т.д. Повторное определение объектов не допускается если не задан параметр @define allow-config-dups 1;
Параметр — список параметров объекта, заключенный в фигурные скобки. Параметры разделяются символом «точка с запятой».
Опция — модификаторы параметров;
Определение объекта завершается символом «точка с запятой».

Пример: определение объекта типа источник и именем s_internal:

source s_internal { internal(); };

Пример: определение объекта типа приемник:

destination d_net { tcp("127.0.0.1" port(1000) log_fifo_size(1000)); };

Для приемника определен параметр tcp c тремя опциями — IP-адрес, IP-порт и размер буфера.

Далее на определенные объекты можно ссылаться по его идентификатору, например в определении объекта «путь»:

log { source(s_internal); destination(d_net); };

Параметры объектов могут иметь обязательные и необязательные опции. Обязательные опции являются позиционными и должны быть указаны в заданном порядке. Необязательные опции имеют формат
<имя>(<значение>) и могут указываться в любом порядке.

Пример: Источник s_demo_stream имеет один параметр — драйвер источника unix-stream(), который имеет одну обязательную опцию — имя сокета, и необязательные опции — max_connection и group:

source s_demo_stream1 { unix-stream("<path-to-socket>" max-connections(10) group(log)); };

Объекты могут использоваться до их определения;
Объекты могут определяться при их использовании (inline), что полезно при однократном применении, например, фильтров;
Строки, начинающиеся с символа «#» считаются комментариями и игнорируются;

Синтаксис определения пути:

log {
 source(s1); source(s2); ...
 optional_element(filter1|parser1|rewrite1);
 optional_element(filter2|parser2|rewrite2);
 ...
 destination(d1); destination(d2); ...
 flags(flag1[, flag2...]);
};

Пример определения источника, приемника и простого пути:

source s_localhost {
    network(ip(127.0.0.1) port(1999));
};
destination d_tcp {
    network("10.1.2.3" port(1999) localport(999));
};
log {
    source(s_localhost);
    destination(d_tcp);
};

Тот же пример определения простого пути с использованием inline-определений источника и приемника:

log {
    source {
        network(ip(127.0.0.1) port(1999));
    };
    destination {
        network("10.1.2.3" port(1999) localport(999));
    };
};

В конфигурации syslog-ng поддерживаются глобальные опции для управления использование DNS, форматами временных отметок и других общих параметров. Синтаксис определения опций:

options { option1(params); option2(params); ... };

Пример применения глобальных опций:

Отключения разрешения имен через DNS:

options { use-dns(no); };

Перечень основных источников, приемников и фильтров:

Таблица 1. Драйверы источников

Название	Описание	Комментарий
file()	Получение сообщений из указанного файла.
internal()	Сообщения, генерируемые службой syslog-ng.
network()	Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS..
pipe()	Чтение сообщений из указанного именованного потока.
program()	Запуск указанного приложения и чтение сообщений из его стандартного вывода.
sun-stream() sun-streams()	Чтение указанного устройства STREAMS (только в системах Solaris).
syslog()	Прием сообщений по протоколу IETF-syslog.
system()	Автоматическое определение платформы и сбор стандартных для этой платформы журналов.
systemd-journal()	Прямое получение сообщений от служб журналов на платформах, использующих systemd.
systemd-syslog()	Получение сообщений через сокет от служб журналов на платформах, использующих systemd.
unix-dgram()	Получение сообщений через указанный сокет SOCK_DGRAM.
unix-stream()	Получение сообщений через указанный сокет SOCK_STREAM.

Таблица 2. Драйверы приемников

Название	Описание	Комментарий
elasticsearch elasticsearch2	Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версия 2 и новее.
file()	Запись сообщений в указанный файл.
hdfs()	Запись сообщений в указанный файл на узле Hadoop Distributed File System (HDFS).
kafka()	Публикация сообщений подписчикам через шину Apache Kafka.
loggly()	Отправка сообщения провайдеру Loggly (https://www.loggly.com/).
logmatic()	Отправка сообщения провайдеру Logmatic.io (https://logmatic.io/).
mongodb()	Сохранение сообщений в СУБД MongoDB.
network()	Отправка сообщений на удаленный хост по протоколу BSD через сети IPv4 IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS.
pipe()	Запись сообщений в указанный именованный поток.
program()	Запуск указанной программы и отправка сообщений на ее стандартный ввод.
sql()	Сохранение сообщений в СУБД SQL. Требует установки и настройки СУБД.
syslog()	Отправка сообщений на удаленный хост по протоколу IETF-syslog protocol. Поддерживает сетевые протоколы TCP, UDP и TLS.
unix-dgram()	Отправка сообщений в формате BSD через указанный сокет SOCK_DGRAM.
unix-stream()	Отправка сообщений в формате Linux через указанный сокет SOCK_STREAM.
usertty()	Отправка сообщений на терминал указанного пользователя если сессия пользователя активна.

Таблица 3. Доступные фильтры.

Название	Описание	Комментарий
facility()	Фильтрация сообщений по указанному объекту (facility).
filter()	Вызов другого фильтра.
host()	Фильтрация сообщений по имени хоста-отправителя.
inlist()	Фильтрация сообщений по черным и белым спискам в файлах.
level() priority()	Фильтрация сообщений по приоритету.
match()	Фильтрация по регулярным выражениям, применяемым к заголовку и содержимому сообщения.
message()	Фильтрация по регулярным выражениям, применяемым к содержимому сообщения.
netmask()	Фильтрация сообщений по IP-адресу хоста-отправителя.
program()	Фильтрация сообщений по названию приложения.
source()	Фильтрация сообщений по указанному источнику.
tags()	Фильтрация сообщений по наличию указанных тегов.

Служба rsyslog

Расположение файлов конфигурации

основной файл /etc/rsyslog.conf/;
дополнительные файлы .conf в каталоге /etc/rsyslog.d;

См. man rsyslog.conf

Служба logrotate

Расположение файлов конфигурации

основной файл /etc/logrotate.conf;
дополнительные файлы .conf /etc/logrotate.d;

Настройки по умолчанию (основной файл конфигурации /etc/logrotate.conf):

weekly — файлы журналов подвергаются ротации, если текущий день недели меньше дня недели последней ротации или если со времени последней ротации прошло больше недели;
rotate <количество> — файлы журнала ротируются указанное количество раз перед тем, как будут удалены или отправлены на адрес, указанный в директиве mail. Если количество равно нулю, прежние версии удаляются, а не ротируются. Количество по умолчанию — 4;
create <режим> <владелец> <группа> — сразу после ротации (до запуска сценария postrotate) создать файл журнала (с таким же именем, как у только что ротированного файл журнала). Поле режим определяет режим для файла журнала в восьмеричном представлении (как в chmod(2)), поле владелец определяет имя пользователя который является владельцем этого файла журнала, и поле группа определяет группу, которой принадлежит файл журнала. Любой из этих атрибутов может быть пропущен, в таком случае для пропущенных атрибутов будут использоваться атрибуты исходного файла журнала. Эта опция может быть отключена с помощью опции nocreate;

Подробное описание см. man logrotate.

Взаимная замена служб rsyslog/syslog-ng

Замена пакетов

B Astra Linux Special Edition x.7 служба rsyslog не поддерживается. Если служба rsyslog была установлена ранее, то для замены службы rsyslog на службу syslog-ng выполнить команду:

sudo apt install syslog-ng

При выполнении указанной команды будут произведены следующие действия:

остановка заменяемой службы;
удаление пакета, предоставляющего удаляемую службу;
установка пакета с новой службой.

Конфигурационные файлы заменяемой службы при этом не удаляются и могут быть использованы либо при обратной замене служб, либо для создания аналогичных настроек для новой службы.

Миграция конфигурационных файлов

Для сохранения параметров записи журналов при замене служб необходимо обеспечить для новой службы наличие конфигурационных файлов, аналогичных конфигурационным файлам заменяемой службы. В состав некоторых пакетов входят конфигурационные файлы для какой-либо службы управления журналами. Для таких пакетов, по мере их выявления, в Astra Linux создаются и включаются в состав пакетов аналогичные альтернативные конфигурации для другой службы.

Для проверки синтаксической корректности конфигурационных файлов службы syslog-ng можно использовать команду:

sudo syslog-ng -s

Далее в качестве примера приведено соответствие конфигураций rsyslog и syslog-ng некоторых пакетов. :

Конфигурация rsyslog	Конфигурация syslog-ng
/etc/rsyslog.d/21-cloudinit.conf	/etc/syslog-ng/conf.d/21-cloudinit.conf
# Log cloudinit generated log messages to file :syslogtag, isequal, "[CLOUDINIT]" /var/log/cloud-init.log # comment out the following line to allow CLOUDINIT messages through. # Doing so means you'll also get CLOUDINIT messages in /var/log/syslog & stop	log { source(s_src); filter { message("^.CLOUDINIT.$"); }; destination { file("/var/log/cloud-init.log"); }; flags( final); };
/etc/rsyslog.d/49-haproxy.conf	/etc/rsyslog-ng/conf.d/49-haproxy.conf
# Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile :programname, startswith, "haproxy" { /var/log/haproxy.log stop }	log { source { unix-dgram("/var/lib/haproxy/dev/log"); }; filter { program("haproxy"); }; destination { file("/var/log/haproxy.log"); }; flags( final); };
/etc/rsyslog.d/20-ufw.conf	/etc/rsyslog-ng/conf.d/20-ufw.conf
# Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& stop	log { source(s_src); filter { message("^.UFW.$"); }; destination { file("/var/log/ufw.log"); }; # flags( final); };
/etc/rsyslog.d/jetty9.conf	/etc/rsyslog-ng/conf.d/jetty9.conf
# Send Jetty messages to jetty.out when using systemd :programname, startswith, "jetty9" { /var/log/jetty9/jetty-console.log stop }	log { source(s_src); filter { program("jetty9"); }; destination { file("/var/log/jetty9/jetty-console.log"); }; flags( final); };
/etc/rsyslog.d/postfix.conf	/etc/rsyslog-ng/conf.d/postfix.conf
# Create an additional socket in postfix's chroot in order not to break # mail logging when rsyslog is restarted. If the directory is missing, # rsyslog will silently skip creating the socket. $AddUnixListenSocket /var/spool/postfix/dev/log	log { source { unix-stream("/var/spool/postfix/dev/log" keep-alive(yes)); }; filter { program("postfix"); }; destination(d_syslog); };
/etc/rsyslog.d/tomcat9.conf	/etc/rsyslog-ng/conf.d/tomcat9.conf
# Send Tomcat messages to catalina.out when using systemd $template TomcatFormat, "[%timegenerated:::date-year%- %timegenerated:::date-month%- %timegenerated:::date-day% %timegenerated:::date-hour%: %timegenerated:::date-minute%: %timegenerated:::date-second%] [%syslogseverity-text%]%msg%\n" :programname, startswith, "tomcat9" { /var/log/tomcat9/catalina.out;TomcatFormat stop }	log { source(s_src); filter { program("tomcat9"); }; destination { file("/var/log/tomcat9/catalina.out", template("[$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC] [$PRIORITY]$MSG\n")); }; flags( final); };

Инструмент сбора журналов astra-create-debug-logs

В состав дистрибутивов ОС Astra Linux входит инструмент командной строки astra-create-debug-logs, предназначенный для автоматического сбора архива журналов системных служб.
Для создания архива журналов инструмент должен быть запущен от имени суперпользователя:

sudo astra-create-debug-logs

Файл с архивом журналов создаётся в каталоге /tmp/.

Расположение файлов журналов основных системных служб

Для справки в таблице ниже приведено расположение файлов журналов некоторых наиболее часто используемых служб:

Служба	Путь к файлу журнала
WEB-сервер Apache2	/var/log/apache2/
Система управления печатью Cups	/var/log/cups/
Почтовый сервер IMAP/Pop3 Dovecot	Необходимо включить запись в журнал в конфигурационном файле /etc/dovecot/conf.d/10-logging.conf в параметре log_path. Например, указать: /var/log/dovecot.log
Почтовый агент Exim4	/var/log/exim4/
Системный журнал Syslog	/var/log/syslog*
Samba	/var/log/samba/
X server	/var/log/Xorg.*.log
СУБД PostgreSQL	/var/lib/postgres/версия/кластер/pg_log
Журнал сообщений ядра	/var/log/kern.log
Журнал доменной службы ALD	/var/log/ald/
Двоичные файлы parsec аудита	/var/log/parsec/
Система контроля целостности файлов afick	/var/log/afick/
Сервер FTP Vsftpd	/var/log/vsftpd.log.*

Источник

устанавливается по умолчанию при установке оперативных обновлений Astra Linux x.7;
при установке замещает собой службу rsyslog. Служба rsyslog при этом полностью удаляется.

Службы управления журналами

syslog-ng — служба управления журналами syslog-ng по умолчанию используется в Astra Linux Special Edition x.7, доступна в репозиториях более ранних очередных обновлений;
rsyslog — служба управления журналами rsyslog по умолчанию используется в Astra Linux Common Edition и Astra Linux Special Edition ранее очередного обновления x.7, доступна в основном репозитории Astra Linux Special Edition x.7;
syslog (sysklogd) — служба управления журналами syslog в настоящее время в Astra Linux не используется;
logrotate — служба архивирования и очистки (ротации) журналов.

Основные возможности служб:

Получение и передача сообщение по сетевым протоколам TCP/UDP/… с возможностью настройки IP-портов и IP-адресов;
Загрузка внешних модулей;
Фильтрация и перенаправление сообщений по имени программы, источнику, номеру процесса и т.д.;
Удаление ненужных сообщений;

Служба syslog-ng

Расположение файлов конфигурации

основной файл: /etc/syslog-ng/syslog-ng.conf;
дополнительные файлы .conf в каталоге /etc/syslog-ng/conf.d.

Базовые принципы функционирования

фильтры — правила, применяемые для селекции сообщений;
анализаторы (parsers) — правила для анализа и разбора сообщений;
модификаторы (rewriting rules) — правила для модификации сообщений.

Базовые принципы конфигурации

Конфигурационный файл состоит из определений объектов. Базовый синтаксис определения объекта:

<тип_объекта> <идентификатор_объекта> { <параметр>(<опция> ..., ...) ...; ... };

где:

тип объекта — один из типов:
- source — источник;
- destination — приемник;
- log — путь;
- filter — фильтр;
- parser — анализатор;
- rewrite rule — модификатор;
- template — шаблон;
- option — глобальные опции.
Идентификатор объекта — уникальное имя, определяющее объект. Имена регистр-зависимые. Имена, совпадающие с зарезервированными словами должны заключаться в кавычки. Рекомендуется использовать имена с префиксами, указывающими на тип объекта, например, префикс «s_» для источников, префикс «d_» для приемников и т.д. Повторное определение объектов не допускается если не задан параметр @define allow-config-dups 1;
Параметр — список параметров объекта, заключенный в фигурные скобки. Параметры разделяются символом «точка с запятой».
Опция — модификаторы параметров;
Определение объекта завершается символом «точка с запятой».

Пример: определение объекта типа источник и именем s_internal:

source s_internal { internal(); };

Пример: определение объекта типа приемник:

destination d_net { tcp("127.0.0.1" port(1000) log_fifo_size(1000)); };

Для приемника определен параметр tcp c тремя опциями — IP-адрес, IP-порт и размер буфера.

Далее на определенные объекты можно ссылаться по его идентификатору, например в определении объекта «путь»:

log { source(s_internal); destination(d_net); };

source s_demo_stream1 { unix-stream("<path-to-socket>" max-connections(10) group(log)); };

Объекты могут использоваться до их определения;
Объекты могут определяться при их использовании (inline), что полезно при однократном применении, например, фильтров;
Строки, начинающиеся с символа «#» считаются комментариями и игнорируются;

Синтаксис определения пути:

log {
 source(s1); source(s2); ...
 optional_element(filter1|parser1|rewrite1);
 optional_element(filter2|parser2|rewrite2);
 ...
 destination(d1); destination(d2); ...
 flags(flag1[, flag2...]);
};

Пример определения источника, приемника и простого пути:

source s_localhost {
    network(ip(127.0.0.1) port(1999));
};
destination d_tcp {
    network("10.1.2.3" port(1999) localport(999));
};
log {
    source(s_localhost);
    destination(d_tcp);
};

Тот же пример определения простого пути с использованием inline-определений источника и приемника:

log {
    source {
        network(ip(127.0.0.1) port(1999));
    };
    destination {
        network("10.1.2.3" port(1999) localport(999));
    };
};

options { option1(params); option2(params); ... };

Пример применения глобальных опций:

Отключения разрешения имен через DNS:

options { use-dns(no); };

Перечень основных источников, приемников и фильтров:

Таблица 1. Драйверы источников

Название	Описание	Комментарий
file()	Получение сообщений из указанного файла.
internal()	Сообщения, генерируемые службой syslog-ng.
network()	Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS..
pipe()	Чтение сообщений из указанного именованного потока.
program()	Запуск указанного приложения и чтение сообщений из его стандартного вывода.
sun-stream() sun-streams()	Чтение указанного устройства STREAMS (только в системах Solaris).
syslog()	Прием сообщений по протоколу IETF-syslog.
system()	Автоматическое определение платформы и сбор стандартных для этой платформы журналов.
systemd-journal()	Прямое получение сообщений от служб журналов на платформах, использующих systemd.
systemd-syslog()	Получение сообщений через сокет от служб журналов на платформах, использующих systemd.
unix-dgram()	Получение сообщений через указанный сокет SOCK_DGRAM.
unix-stream()	Получение сообщений через указанный сокет SOCK_STREAM.

Таблица 2. Драйверы приемников

Название	Описание	Комментарий
elasticsearch elasticsearch2	Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версия 2 и новее.
file()	Запись сообщений в указанный файл.
hdfs()	Запись сообщений в указанный файл на узле Hadoop Distributed File System (HDFS).
kafka()	Публикация сообщений подписчикам через шину Apache Kafka.
loggly()	Отправка сообщения провайдеру Loggly (https://www.loggly.com/).
logmatic()	Отправка сообщения провайдеру Logmatic.io (https://logmatic.io/).
mongodb()	Сохранение сообщений в СУБД MongoDB.
network()	Отправка сообщений на удаленный хост по протоколу BSD через сети IPv4 IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS.
pipe()	Запись сообщений в указанный именованный поток.
program()	Запуск указанной программы и отправка сообщений на ее стандартный ввод.
sql()	Сохранение сообщений в СУБД SQL. Требует установки и настройки СУБД.
syslog()	Отправка сообщений на удаленный хост по протоколу IETF-syslog protocol. Поддерживает сетевые протоколы TCP, UDP и TLS.
unix-dgram()	Отправка сообщений в формате BSD через указанный сокет SOCK_DGRAM.
unix-stream()	Отправка сообщений в формате Linux через указанный сокет SOCK_STREAM.
usertty()	Отправка сообщений на терминал указанного пользователя если сессия пользователя активна.

Таблица 3. Доступные фильтры.

Название	Описание	Комментарий
facility()	Фильтрация сообщений по указанному объекту (facility).
filter()	Вызов другого фильтра.
host()	Фильтрация сообщений по имени хоста-отправителя.
inlist()	Фильтрация сообщений по черным и белым спискам в файлах.
level() priority()	Фильтрация сообщений по приоритету.
match()	Фильтрация по регулярным выражениям, применяемым к заголовку и содержимому сообщения.
message()	Фильтрация по регулярным выражениям, применяемым к содержимому сообщения.
netmask()	Фильтрация сообщений по IP-адресу хоста-отправителя.
program()	Фильтрация сообщений по названию приложения.
source()	Фильтрация сообщений по указанному источнику.
tags()	Фильтрация сообщений по наличию указанных тегов.

Служба rsyslog

Расположение файлов конфигурации

основной файл /etc/rsyslog.conf/;
дополнительные файлы .conf в каталоге /etc/rsyslog.d;

См. man rsyslog.conf

Служба logrotate

Расположение файлов конфигурации

основной файл /etc/logrotate.conf;
дополнительные файлы .conf /etc/logrotate.d;

Настройки по умолчанию (основной файл конфигурации /etc/logrotate.conf):

weekly — файлы журналов подвергаются ротации, если текущий день недели меньше дня недели последней ротации или если со времени последней ротации прошло больше недели;
rotate <количество> — файлы журнала ротируются указанное количество раз перед тем, как будут удалены или отправлены на адрес, указанный в директиве mail. Если количество равно нулю, прежние версии удаляются, а не ротируются. Количество по умолчанию — 4;
create <режим> <владелец> <группа> — сразу после ротации (до запуска сценария postrotate) создать файл журнала (с таким же именем, как у только что ротированного файл журнала). Поле режим определяет режим для файла журнала в восьмеричном представлении (как в chmod(2)), поле владелец определяет имя пользователя который является владельцем этого файла журнала, и поле группа определяет группу, которой принадлежит файл журнала. Любой из этих атрибутов может быть пропущен, в таком случае для пропущенных атрибутов будут использоваться атрибуты исходного файла журнала. Эта опция может быть отключена с помощью опции nocreate;

Подробное описание см. man logrotate.

Взаимная замена служб rsyslog/syslog-ng

Замена пакетов

Для замены службы syslog-ng на службу rsyslog:

sudo apt install rsyslog

Для замены службы rsyslog на службу syslog-ng:

sudo apt install syslog-ng

При выполнении указанных команд будут произведены следующие действия:

остановка заменяемой службы;
удалении пакета, предоставляющего удаляемую службу;
установка пакета с новой службой.

Миграция конфигурационных файлов

Для проверки синтаксической корректности конфигурационных файлов службы syslog-ng можно использовать команду:

sudo syslog-ng -s

Далее в качестве примера приведено соответствие конфигураций rsyslog и syslog-ng некоторых пакетов. :

Конфигурация rsyslog	Конфигурация syslog-ng
/etc/rsyslog.d/21-cloudinit.conf	/etc/rsyslog-ng/conf.d/21-cloudinit.conf
# Log cloudinit generated log messages to file :syslogtag, isequal, "[CLOUDINIT]" /var/log/cloud-init.log # comment out the following line to allow CLOUDINIT messages through. # Doing so means you'll also get CLOUDINIT messages in /var/log/syslog & stop	log { source(s_src); filter { message("^.CLOUDINIT.$"); }; destination { file("/var/log/cloud-init.log"); }; flags( final); };
/etc/rsyslog.d/49-haproxy.conf	/etc/rsyslog-ng/conf.d/49-haproxy.conf
# Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile :programname, startswith, "haproxy" { /var/log/haproxy.log stop }	log { source { unix-dgram("/var/lib/haproxy/dev/log"); }; filter { program("haproxy"); }; destination { file("/var/log/haproxy.log"); }; flags( final); };
/etc/rsyslog.d/20-ufw.conf	/etc/rsyslog-ng/conf.d/20-ufw.conf
# Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& stop	log { source(s_src); filter { message("^.UFW.$"); }; destination { file("/var/log/ufw.log"); }; # flags( final); };
/etc/rsyslog.d/jetty9.conf	/etc/rsyslog-ng/conf.d/jetty9.conf
# Send Jetty messages to jetty.out when using systemd :programname, startswith, "jetty9" { /var/log/jetty9/jetty-console.log stop }	log { source(s_src); filter { program("jetty9"); }; destination { file("/var/log/jetty9/jetty-console.log"); }; flags( final); };
/etc/rsyslog.d/postfix.conf	/etc/rsyslog-ng/conf.d/postfix.conf
# Create an additional socket in postfix's chroot in order not to break # mail logging when rsyslog is restarted. If the directory is missing, # rsyslog will silently skip creating the socket. $AddUnixListenSocket /var/spool/postfix/dev/log	log { source { unix-stream("/var/spool/postfix/dev/log" keep-alive(yes)); }; filter { program("postfix"); }; destination(d_syslog); };
/etc/rsyslog.d/tomcat9.conf	/etc/rsyslog-ng/conf.d/tomcat9.conf
# Send Tomcat messages to catalina.out when using systemd $template TomcatFormat, "[%timegenerated:::date-year%- %timegenerated:::date-month%- %timegenerated:::date-day% %timegenerated:::date-hour%: %timegenerated:::date-minute%: %timegenerated:::date-second%] [%syslogseverity-text%]%msg%n" :programname, startswith, "tomcat9" { /var/log/tomcat9/catalina.out;TomcatFormat stop }	log { source(s_src); filter { program("tomcat9"); }; destination { file("/var/log/tomcat9/catalina.out", template("[$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC] [$PRIORITY]$MSGn")); }; flags( final); };

Инструмент сбора журналов astra-create-debug-logs

sudo astra-create-debug-logs

Файл с архивом журналов создаётся в каталоге /tmp/.

Расположение файлов журналов основных системных служб

Служба	Путь к файлу журнала
WEB-сервер Apache2	/var/log/apache2/
Система управления печатью Cups	/var/log/cups/
Почтовый сервер IMAP/Pop3 Dovecot	Необходимо включить запись в журнал в конфигурационном файле /etc/dovecot/conf.d/10-logging.conf в параметре log_path. Например, указать: /var/log/dovecot.log
Почтовый агент Exim4	/var/log/exim4/
Системный журнал Syslog	/var/log/syslog*
Samba	/var/log/samba/
X server	/var/log/Xorg.*.log
СУБД PostgreSQL	/var/lib/postgres/версия/кластер/pg_log
Журнал сообщений ядра	/var/log/kern.log
Журнал доменной службы ALD	/var/log/ald/
Двоичные файлы parsec аудита	/var/log/parsec/
Система контроля целостности файлов afick	/var/log/afick/
Сервер FTP Vsftpd	/var/log/vsftpd.log.*

Системные администраторы, да и обычные пользователи Linux, часто должны смотреть лог файлы для устранения неполадок. На самом деле, это первое, что должен сделать любой сисадмин при возникновении любой ошибки в системе.

Сама операционная система Linux и работающие приложения генерируют различные типы сообщений, которые регистрируются в различных файлах журналов. В Linux используются специальное программное обеспечение, файлы и директории для хранения лог файлов. Знание в каких файлах находятся логи каких программ поможет вам сэкономить время и быстрее решить проблему. В этой статье мы рассмотрим основные части системы логирования в Linux, файлы логов, а также утилиты, с помощью которых можно посмотреть логи Linux.

Расположение логов по умолчанию

Большинство файлов логов Linux находятся в папке /var/log/ вы можете список файлов логов для вашей системы с помощью команды ls:

ls -l /var/log/

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторые из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

/var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.
/var/log/dmesg — содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.
/var/log/auth.log — содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.
/var/log/boot.log — Содержит информацию, которая регистрируется при загрузке системы.
/var/log/daemon.log — Включает сообщения от различных фоновых демонов
/var/log/kern.log — Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.
/var/log/lastlog — Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.
/var/log/maillog /var/log/mail.log — журналы сервера электронной почты, запущенного в системе.
/var/log/user.log — Информация из всех журналов на уровне пользователей.
/var/log/Xorg.x.log — Лог сообщений Х сервера.
/var/log/alternatives.log — Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.
/var/log/btmp — лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp
/var/log/cups — Все сообщения, связанные с печатью и принтерами.
/var/log/anaconda.log — все сообщения, зарегистрированные при установке сохраняются в этом файле
/var/log/yum.log — регистрирует всю информацию об установке пакетов с помощью Yum.
/var/log/cron — Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.
/var/log/secure — содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.
/var/log/wtmp или /var/log/utmp — системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.
/var/log/faillog — лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.
/var/log/mysqld.log — файлы логов Linux от сервера баз данных MySQL.
/var/log/httpd/ или /var/log/apache2 — лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log
/var/log/lighttpd/ — логи linux веб-сервера lighttpd
/var/log/conman/ — файлы логов клиента ConMan,
/var/log/mail/ — в этом каталоге содержатся дополнительные логи почтового сервера
/var/log/prelink/ — Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о .so файлах, которые были изменены программой.
/var/log/audit/— Содержит информацию, созданную демоном аудита auditd.
/var/log/setroubleshoot/ — SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.
/var/log/samba/ — содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.
/var/log/sa/ — Содержит .cap файлы, собранные пакетом Sysstat.
/var/log/sssd/ — Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

Чтобы посмотреть логи на Linux удобно использовать несколько утилит командной строки Linux. Это может быть любой текстовый редактор, или специальная утилита. Скорее всего, вам понадобятся права суперпользователя для того чтобы посмотреть логи в Linux. Вот команды, которые чаще всего используются для этих целей:

less;
more;
cat;
head;
grep;
tail;
zcat;
zgrep;
zmore;
vi;
nano.

Я не буду останавливаться подробно на каждой из этих команд, поскольку большинство из них уже подробно рассмотрены на нашем сайте. Но приведу несколько примеров. Просмотр логов Linux выполняется очень просто:

Смотрим лог /var/log/dmesg, с возможностью прокрутки:

less /var/log/dmesg

Просмотр логов Linux, в реальном времени:

tail -f /var/log/dmesg

Открываем лог файл dmesg:

cat /var/log/dmesg

Первые строки dmesg:

head /var/log/dmesg

Выводим только ошибки из /var/log/messages:

grep -i error /var/log/dmesg

Кроме того, посмотреть логи на linux можно и с помощью графических утилит. Программа Журналы может быть использована для удобного просмотра и отслеживания системных журналов на ноутбуке или персональном компьютере с Linux.

Вы можете установить программу в любой системе с установленным X сервером. Также для просмотра логов может использоваться любой графический тестовый редактор.

Кроме того, у каждого сервиса есть свой лог файл, который можно посмотреть с помощью утилиты journalctl.

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

Если вы столкнулись с проблемами в работе сервера, первое, что нужно сделать — посмотреть логи Linux. В системный журнал записываются диагностические сообщения, поступающие от различных компонентов операционной системы, таких как ядро или службы, поэтому с большой долей вероятности причина сбоев будет найдена.

Каждое сообщение генерируется в результате возникновения какого-либо события в операционной системе. Событием может быть остановка службы, авторизации пользователя в системе или неполадки в работе приложения. События имеют определенный приоритет, в зависимости от степени критичности. В Linux различают следующие типы событий:

emerg — авария, наивысший приоритет;
alert — тревога;
crit — критическое событие;
err — ошибка;
warn — внимание;
notice — уведомление;
info — информационное сообщение;
debug — отладочная информация;

На сегодняшний день в Linux основными службами сбора логов являются rsyslog и systemd-journald, они работают независимо друг от друга и входят в состав большинства современных дистрибутивов.

rsyslog

Журналы службы находятся в директории “/var/log/” в виде обычных текстовых файлов. В зависимости от типа события, сообщения записываются в разные файлы. Например файл “/var/log/auth.log” содержит информацию о входе пользователей в систему, а в файл “/var/log/kern.log” записываются сообщения ядра. В разных дистрибутивах названия файлов могут отличаться, поэтому для точного понимания куда именно происходит запись сообщений рассмотрим файл конфигурации “/etc/rsyslog.d/50-default.conf”.

Правила описывают место хранения логов в зависимости от типа сообщения. В левой части строки указан тип сообщения в формате “[Источник].[Приоритет]”, а в правой части имя файла журнала. При записи типа сообщения можно применять символ “*”, обозначающий любое значение или параметр “none”, обозначающий исключение из списка. Рассмотрим более подробно первые два правила.

“auth,authpriv.* /var/log/auth.log” “*.*;auth,authpriv.none -/var/log/syslog”

Первое правило означает, что все сообщения принятые от механизма авторизации будут записаны в файл “/var/log/auth.log”. В этом файле будут зарегистрированы все попытки входа пользователей в систему, как удачные так и не удачные. Второе правило говорит о том, что все сообщения, кроме тех, которые связаны с авторизацией будут записаны в файл “/var/log/syslog”. Именно к этим файлам приходится обращаться наиболее часто. Следующие правила определяют место хранения журналов ядра “kern.*” и почтовой службы “mail.*”

Журналы логов можно открыть любой утилитой для просмотра текста, например less, cat, tail. Откроем файл “/var/log/auth.log”

less /var/log/auth.log

Каждая строка файла является отдельным сообщением, поступившим от приложения или службы. Все сообщения, независимо от источника имеют единый формат и состоят из пяти частей. Рассмотрим их на примере выделенного сообщения на скриншоте.

Дата и время регистрации сообщения — “Feb 12 06:18:33”
Имя компьютера, с которого пришло сообщение — “vds”
Имя программы или службы, к которой относится сообщение — “sshd”
Идентификатор процесса, отправившего сообщение — [653]
Текст сообщения — “Accepted password for mihail from 188.19.42.165 port 2849 ssh2”

Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:

В этом файле также фиксируется выполнение команд с повышенными правами.

Откроем файл /var/log/syslog

На скриншоте выделено сообщение о выключении сетевого интерфейса.

Для поиска нужной информации в больших текстовых файлах можно использовать утилиту grep. Найдем все сообщения от службы pptpd в файле “/var/log/syslog”

grep 'pptpd' /var/log/syslog

Во время диагностики можно использовать утилиту tail, которая выводит последние строки в файле. Команда “tail -f /var/log/syslog” позволит наблюдать запись логов в реальном времени.

Служба rsyslog является очень гибкой, высокопроизводительной и может использоваться для сбора логов как на локальных системах, так и на уровне предприятия. Полную документацию можно найти на официальном сайте https://www.rsyslog.com/

Запись логов происходит непрерывно и размер файлов постоянно растет. Механизм ротации обеспечивает автоматическое архивирование старых журналов и создание новых. В зависимости от правил, обработка журналов может выполняться ежедневно, еженедельно, ежемесячно или при достижении файлом определенного размера. По мере создания новых архивов, старые могут быть просто удалены или предварительно отправлены по электронной почте. Ротация выполняется утилитой logrotate. Основная конфигурация находится в файле “/etc/logrotate.conf”, также обрабатывается содержимое файлов в директории “/etc/logrotate.d/”

Новые правила можно записывать в основной файл конфигурации, но более правильным будет создание отдельного файла в директории “/etc/logrotate.d/” По умолчанию в директории уже содержится несколько файлов.

Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.

В начале правила указывается путь к файлу журнала, затем в фигурных скобках перечисляются директивы.

rotate 7 — необходимо постоянно хранить 7 файлов
daily — ежедневно будет создаваться новый файл
compress — старые файлы необходимо архивировать.

На скриншоте видно, что в каталоге “/var/log/” находится основной журнал “syslog” и семь архивов, что соответствует правилам ротации.

Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”

journald

Служба сбора логов systemd-journald является частью системы инициализации systemd. Файлы журнал хранятся в директории “/var/log/journal/” в специальном формате и могут быть открыты с помощью утилиты journalctl. Формат записей такой же как у службы rsyslog.

Команда journalctl без параметров выводит на экран все записи, но учитывая, что объем журнала может достигать нескольких гигабайт, такой способ просмотра не подходит для практического применения. Рассмотрим некоторые опции утилиты.

вывод записей с момента последней загрузки
journalctl -b
вывод записей за определенный период времени
journalctl -S "2020-02-17 12:00" -U "2020-02-17 12:10"
вывод записей, принятых от определенной службы
journalctl -u pptpd
вывод сообщений ядра
journalctl -k
вывод сообщений с определенным приоритетом, в данном случае будут выведены ошибки и более высокие приоритеты(crit, alert, emerg).
journalctl -p err
вывод сообщений в реальном времени
journalctl -f

Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd

journalctl -u pptpd -p err

Если в качестве аргумента указать путь к исполняемому файлу, утилита выведет все сообщения, отправленные этим файлом. Выведем сообщения, отправленные файлом “/usr/bin/sudo” начиная с 04:15 18-го февраля 2020 года. Фактически будут выведены все команды, выполненные с повышенными правами.

journalctl -S "2020-02-18 04:15" /usr/bin/sudo

Для того, чтобы узнать сколько места на диске занимают файлы журнала, выполним команду

journalctl --disk-usage

Для ограничения объема журнала размером 1Gb выполним команду

journalctl --vacuum-size=1G

Открытие бинарных файлов

В заключении рассмотрим несколько специальных файлов в директории “/var/log/”, в которых регистрируются попытки входа пользователей в систему. Это бинарные файлы, которые могут быть открыты только специальными утилитами.

/var/log/wtmp — содержит информацию об успешном входе пользователей в систему, для открытия используется утилита last

/var/log/btmp — в файле регистрируются все неудачные попытки входа в систему, открывается командой lastb с повышенными правами. Параметр -n определяет количество выводимых строк начиная с конца файла.

/var/log/lastlog — содержит время последнего входа для каждой учетной записи, может быть открыт одноименной утилитой lastlog

Все факты начала и окончания работы пользователя фиксируется в журнале /var/log/auth.log на клиентской машине.
Например:
Feb 19 12:32:48 nd-nout fly-dm: :0[3421]: pam_unix(fly-dm:session): session opened for user ivanov by (uid=0)
Указанная запись содержит информацию о начале сессии для пользователя с учетной записью ivanov.
Feb 19 13:15:38 ac-old login[3865]: pam_unix(login:session): session closed for user petrovich
Указанная запись содержит информацию о завершении сессии для пользователя с учетной записью petrovich.
Кроме того, информация о начале и завершении работы пользователя попадает в журнал подсистемы безопасности parsec: /var/log/parsec/user.mlog, доступный для просмотра при помощи утилиты userlog. В журнале регистрируются события с типами auth (вход), exit (выход).

Например:

ac-old:~# userlog 'Tue Feb 19 12:50:00 2013' '/bin/login' <26828,26778,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 12:57:59 2013' '/usr/bin/fly-dm' <25927,3462,0,0,0> [s] exit("fly-dm","root") 'Tue Feb 19 13:14:52 2013' '/bin/login' <3796,3680,0,0,0> [s] auth("login","root") 'Tue Feb 19 13:15:33 2013' '/bin/login' <3865,3683,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:15:39 2013' '/bin/login' <3865,3683,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 13:19:53 2013' '/bin/login' <3992,3898,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:20:13 2013' '/bin/login' <3992,3898,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 13:20:23 2013' '/bin/login' <4070,4020,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:20:31 2013' '/bin/login' <4070,4020,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 13:27:48 2013' '/bin/login' <4212,4091,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:27:54 2013' '/bin/login' <4212,4091,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 13:33:51 2013' '/bin/login' <4327,4234,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:33:55 2013' '/bin/login' <4327,4234,0,2500,0> [s] exit("login","petrovich") 'Tue Feb 19 13:39:49 2013' '/bin/login' <4440,4348,0,2500,0> [s] auth("login","petrovich") 'Tue Feb 19 13:39:53 2013' '/bin/login' <4440,4348,0,2500,0> [s] exit("login","petrovich")

Описание системы регистрации событий приведено в разделе 10 документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство
по КСЗ. Часть 1». Дополнительная информация приведена на страницах справочного руководства man для расширенной системы протоколирования, доступной по команде man parselog.
В операционной системе специального назначения «Astra Linux Special Edition» обеспечивается регистрация всех событий в соответствии с требованиями документа
«Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» ФСТЭК России, предъявляемых к средствам вычислительной техники третьего класса защищенности.
Регистрация событий может быть проверена следующим образом:
устанавливаем для пользователя (доменного) все возможные флаги аудита:

Событие:

dc-old:~# ald-admin user-aud-get petrovich Audit policy user:petrovich Audit success rules: ocxudntligarmphew nr f flag -- - ---- 0 o open 1 c create 2 x exec 3 u delete 4 d chmod 5 n chown 6 t mount 7 l module 8 i uid 9 g gid 10 a audit 11 r acl 12 m mac 13 p cap 14 h chroot 15 e rename 16 w net Audit fail rules: ocxudntligarmphew nr f flag -- - ---- 0 o open 1 c create 2 x exec 3 u delete 4 d chmod 5 n chown 6 t mount 7 l module 8 i uid 9 g gid 10 a audit 11 r acl 12 m mac 13 p cap 14 h chroot 15 e rename 16 w net

Очищаем журнал событий на ЭВМ:
ac-old:~# > /var/log/parsec/kernel.mlog
Выполняем вход в систему пользователем petrovich. Смотрим журнал событий командой kernlog с фильтрацией по имени пользователя petrovich:

Событие:

ac-old:~# kernlog | grep "petrovich*" [p] 'Tue Feb 19 13:39:49 2013' '/bin/bash' <4450,4440,2500,2500,2500> [f] open("/ald_home/petrovich/.bash_profile",O_RDONLY) = -2 ENOENT (Нет такого файла иликаталога) [p] 'Tue Feb 19 13:39:49 2013' '/bin/bash' <4450,4440,2500,2500,2500> [f] open("/ald_home/petrovich/.bash_login",O_RDONLY) = -2 ENOENT (Нет такого файла или каталога) [p] 'Tue Feb 19 13:39:49 2013' '/bin/bash' <4450,4440,2500,2500,2500> [f] open("/ald_home/petrovich/.profile",O_RDONLY) = -2 ENOENT (Нет такого файла или каталога) [p] 'Tue Feb 19 13:39:49 2013' '/bin/bash' <4450,4440,2500,2500,2500> [s] open("/ald_home/petrovich/.bash_history",O_RDONLY) = 3 [p] 'Tue Feb 19 13:39:49 2013' '/bin/bash' <4450,4440,2500,2500,2500> [s] open("/ald_home/petrovich/.bash_history",O_RDONLY) = 3 [p] 'Tue Feb 19 13:39:52 2013' '/bin/bash' <4450,4440,2500,2500,2500> [f] open("/ald_home/petrovich/.bash_logout",O_RDONLY) = -2 ENOENT (Нет такого файла или каталога) [p] 'Tue Feb 19 13:39:52 2013' '/bin/bash' <4450,4440,2500,2500,2500> [s] open("/ald_home/petrovich/.bash_history",O_WRONLY | O_APPEND) = 3 [p] 'Tue Feb 19 13:39:52 2013' '/bin/bash' <4450,4440,2500,2500,2500> [s] open("/ald_home/petrovich/.bash_history",O_RDONLY) = 3 [p] 'Tue Feb 19 13:39:52 2013' '/bin/login' <4440,4348,0,2500,0> [s] umount("/ald_home/petrovich/mac/0/0") = 0 [p] 'Tue Feb 19 13:39:52 2013' '/bin/login' <4440,4348,0,2500,0> [s] umount("/ald_home/petrovich/mac") = 0 [p] 'Tue Feb 19 13:39:52 2013' '/bin/login' <4440,4348,0,2500,0> [s] umount("/ald_home/petrovich") = 0 [p] 'Tue Feb 19 13:39:52 2013' '/bin/login' <4440,4348,0,2500,0> [s] umount("/var/private/mac/petrovich/0/0") = 0 [p] 'Tue Feb 19 13:39:52 2013' '/bin/login' <4440,4348,0,2500,0> [s] umount("/var/private/mac/petrovich") = 0 [p] 'Tue Feb 19 13:39:52 2013' '/usr/sbin/pmvarrun' <4453,4440,0,2500,0> [s] create("/var/run/pam_mount/petrovich",O_RDWR | O_CREAT,-rw-------) = 7 [p] 'Tue Feb 19 13:39:52 2013' '/usr/sbin/pmvarrun' <4453,4440,0,2500,0> [s] chown("/var/run/pam_mount/petrovich",2500,0) = 0 [p] 'Tue Feb 19 13:39:53 2013' '/sbin/umount.cifs' <4455,4454,0,2500,0> [s] umount("/ald_home/petrovich") = 0

Имеется множество событий open (открытие файла), mount (монтирование и размонтирование), create (создание объекта), chown (изменение прав доступа пользователя).
В домашнем каталоге пользователя petrovich создаем каталог testdir и в нем файл testfile. Владелец файлов — сам пользователь:

Событие:

dc-old:~# ls -l /ald_export_home/petrovich/ | grep test drwxr-x--- 2 petrovich petrovich 4096 Фев 19 13:50 testdir dc-old:~# ls -l /ald_export_home/petrovich/testdir/ итого 4 -rwxr----- 1 petrovich petrovich 5 Фев 19 13:50 testfile

Устанавливаем на данные файлы флаги аудита:

Событие:

dc-old:/ald_export_home/petrovich# getfaud testdir/ # file: testdir o:ouc:ouc default:o:ouc:ouc dc-old:/ald_export_home/petrovich# getfaud testdir/testfile # file: testdir/testfile o:ouc:ouc

После этого на ЭВМ пользователем petrovich удаляем testdir/testfile, создаем testdir/testfile2. На сервере в журнале /var/log/parsec/kern.mlog регистрируются события:

Событие:

чтение каталога: [f] 'Tue Feb 19 14:07:23 2013' '/usr/sbin/smbd' <6514,3024,0,0,2500> [s] open("/ald_export_home/petrovich/testdir",NO_PERMS | O_NONBLOCK | O_DIRECTORY) = 0 удаление файла: [f] 'Tue Feb 19 14:07:25 2013' '/usr/sbin/smbd' <6514,3024,0,0,2500> [s] unlink("/ald_export_home/petrovich/testdir/testfile (deleted)") = 0 создание файла: [f] 'Tue Feb 19 14:07:34 2013' '/usr/sbin/smbd' <6514,3024,0,0,2500> [s] create("/ald_export_home/petrovich/testdir/testfile2",-rw-r-----) = 0 [f] 'Tue Feb 19 14:07:34 2013' '/usr/sbin/smbd' <6514,3024,0,0,2500> [s] open("/ald_export_home/petrovich/testdir/testfile2",O_RDONLY | O_CREAT | O_NOFOLLOW) = 0 удаленное копирование: f] 'Tue Feb 19 14:12:15 2013' '/usr/bin/scp' <6609,6606,0,0,0> [s] create("/ald_export_home/petrovich/testdir/remote_cp",-rw-r--r--) = 0 [f] 'Tue Feb 19 14:12:15 2013' '/usr/bin/scp' <6609,6606,0,0,0> [s] open("/ald_export_home/petrovich/testdir/remote_cp",O_RDONLY | O_CREAT) = 0

При создании объектов внутри каталога, для которого отслеживаются соответствующие события (create), создание любых объектов в нём регистрируется. При установке на файл мандатного уровня/категории регистрируется событие chmac (изменение мандатных атрибутов).

Событие:

dc-old:/ald_export_home/petrovich# setfaud -s o:ocum:ocum testdir/testfile2 dc-old:/ald_export_home/petrovich# > /var/log/parsec/kernel.mlog dc-old:/ald_export_home/petrovich# chmac 1:0 testdir/testfile2 dc-old:/ald_export_home/petrovich# kernlog [f] 'Tue Feb 19 14:24:55 2013' '/bin/bash' <5891,5887,0,0,0> [s] open("/ald_export_home/petrovich/testdir",NO_PERMS | O_NONBLOCK | O_DIRECTORY) = 0 [f] 'Tue Feb 19 14:24:56 2013' '/usr/sbin/chmac' <6914,5891,0,0,0> [s] parsec_chmac("/ald_export_home/petrovich/testdir/testfile2",{1,0x0},0) = 0

Регистрация событий передачи по линиям и каналам связи является требованием документа ФСТЭК России «Руководящий документ. Автоматизированные системы. Защита
от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» и должна обеспечиваться конструктором АС.
При этом операционная система специального назначения «Astra Linux Special Edition» предоставляет возможность регистрации подобного класса событий. Далее приведен протокол работы пользователя при обмене по сети с использованием утилиты ping.

Событие:

[p] 'Fri Feb 22 12:57:29 2013' '/bin/bash' <6798,6795,2500,2500,0> [s] exec("/bin/ping") = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,0> [s] open("/etc/ld.so.cache",O_RDONLY) = 3 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,0> [s] open("/lib/libresolv.so.2",O_RDONLY) = 3 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,0> [s] open("/lib/libc.so.6",O_RDONLY) = 3 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,0> [s] setuid(2500) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/resolv.conf",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/resolv.conf",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_STREAM,{AF_UNIX,...},{AF_UNIX,/var/run/nscd/socket}) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_STREAM,{AF_UNIX,...},{AF_UNIX,/var/run/nscd/socket}) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/nsswitch.conf",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/ld.so.cache",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/lib/libnss_files.so.2",O_RDONLY) = 4</ [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/host.conf",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/hosts",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/ld.so.cache",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/lib/libnss_dns.so.2",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_DGRAM,{AF_INET,10.0.0.106:41209},{AF_INET,10.0.0.1:53}) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] sendmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:41209},{AF_INET,10.0.0.1:53}) = 29 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] recvmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:41209},{AF_INET,10.0.0.1:53}) = 78 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_DGRAM,{AF_INET,10.0.0.106:48650},{AF_INET,10.0.0.1:1025}) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] sendmsg(SOCK_RAW,{AF_INET,0.0.0.0:1},{AF_INET,10.0.0.1:0}) = 64 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] recvmsg(SOCK_RAW,{AF_INET,0.0.0.0:1},{AF_INET,10.0.0.1:0}) = 84 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/hosts",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_DGRAM,{AF_INET,10.0.0.106:44260},{AF_INET,10.0.0.1:53}) = 0 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] sendmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:44260},{AF_INET,10.0.0.1:53}) = 39 [p] 'Fri Feb 22 12:57:29 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] recvmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:44260},{AF_INET,10.0.0.1:53}) = 96 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] sendmsg(SOCK_RAW,{AF_INET,0.0.0.0:1},{AF_INET,10.0.0.1:0}) = 64 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] recvmsg(SOCK_RAW,{AF_INET,0.0.0.0:1},{AF_INET,10.0.0.1:0}) = 84 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] open("/etc/hosts",O_RDONLY) = 4 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] connect(SOCK_DGRAM,{AF_INET,10.0.0.106:53774},{AF_INET,10.0.0.1:53}) = 0 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] sendmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:53774},{AF_INET,10.0.0.1:53}) = 39 [p] 'Fri Feb 22 12:57:30 2013' '/bin/ping' <6798,6795,2500,2500,2500> [s] recvmsg(SOCK_DGRAM,{AF_INET,10.0.0.106:53774},{AF_INET,10.0.0.1:53}) = 96

В протоколе зафиксированы все факты отправки и приема сетевых пакетов, а также IP-адреса отправителя и получателя. Порядок настройки системы регистрации событий описан в разделе 10 документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1».

Существует известная проблема в версии 1.2: когда на клиентскую машину заходит пользователь под уровнем 0, аудит событий перестает работать корректно. Для исправления на каждой клиентской машине, где будут заходить пользователи, в файле /etc/pam.d/common-session неоьбходимо добавить в конец строку:
session optional pam_ald.so populate_krb5cc
Если на сервер должны заходить пользователи, то на нем так же следует внести эти изменения.
После этого желательно перезагрузить машины.

systemd – это системный менеджер по умолчанию в большинстве основных дистрибутивов Linux, который поставляется с новым демоном ведения журнала под названием «journald».

В течение многих лет системные логи и журналы ядра в традиционной системе SysVinit обрабатывались syslogd, который хранит логи в простых текстовых файлах, тогда как journald хранит логи в двоичном формате.

systemd собирает логи из нескольких источников, таких как система, ядро и различные службы или демоны, и предоставляет решение для централизованного управления через journald.

Это очень оптимизированный процесс, и логи можно просматривать в зависимости от требований, тогда как журналы syslogd анализируются вручную с помощью различных команд, таких как find, grep, cut и т. д.

В этой статье мы продемонстрируем, как просматривать и анализировать системные логи Linux с помощью команды journalctl.

Содержание

Что такое journald?
Что такое journalctl?
1) Как сделать логи постоянным в вашей системе?
2) Понимание полезных флагов journalctl
3) Как использовать journalctl для чтения логов
Просмотр основного журнала с помощью команды journalctl
Отображение логов в обратном порядке
Отображение только “N” последних строк
Проверка логов в реальном времени
Фильтрация определенного лога загрузки
Фильтрация на основе временного интервала
Фильтрация по приоритету
4) Фильтрация по полям
Фильтрация по системному юниту
Фильтрация логов по UID, GID и PID
Фильтр по пути к файлу
Фильтр по пути к устройству
Проверка использования диска
Заключение

Что такое journald?

journald – это демон из systemd, который собирает логи из различных источников, таких как система, ядро и службы, и сохраняет их в двоичном формате для упрощения манипуляций.

Все эти события журналирования обрабатываются демоном journald, который обеспечивает централизованный способ обработки журналов независимо от того, откуда исходят сообщения.

Что такое journalctl?

journalctl – это инструмент командной строки, используемый для просмотра логов, которые собирает демон journald в systemd.

Логи хорошо проиндексированы и структурированы таким образом, что позволяет системным администраторам легко анализировать их и управлять ими на основе различных параметров, таких как фильтрация логов по времени, последовательности загрузки, конкретной службе, серьезности и т. д.

1) Как сделать логи постоянным в вашей системе?

По умолчанию логи включены в большинстве дистрибутивов Linux, но данные журнала хранятся в папке «/run/log/journal/», которая по умолчанию стирается при перезагрузке.

Чтобы сделать их постоянными, выполните следующие действия, которые автоматически создадут для вас каталог «/var/log/journal/».

Обратите внимание: каталог «/var/log/journal/» должен существовать с правильным владельцем и правами, чтобы служба systemd-journald могла хранить свои данные.

От пользователя root откройте файл «/etc/systemd/journald.conf» и раскомментируйте строку, содержащую «Storage = auto», и измените ее на «Storage = persistent».

В качестве альтернативы вы можете использовать команду sed для замены соответствующей строки в файле.

$ sudo sed -i '/Storage/ cStorage=persistent' /etc/systemd/journald.conf

После внесения изменений вы можете подтвердить их вступление в силу, выполнив следующую команду:

-f: показывает только самые последние логи и сообщения журнала в реальном времени.
-e: перейти в конец журнала, чтобы показать последние события.
-r: вывести сообщения логов в обратном хронологическом порядке.
-k: показать только сообщения ядра.
-u: показать только сообщения для указанного модуля systemd.
-b: показать сообщения о конкретной загрузке и отображает текущие загрузочные сообщения, если определенные загрузочные сеансы не включены.
–List-boots: показывает сеансы загрузки в таблице, включая их идентификаторы и временные метки первого и последнего сообщения, относящегося к загрузке.
–Utc: выразить время в формате всемирного координированного времени (UTC).
-p, –priority =: фильтровать вывод по приоритетам сообщений.
-S, –since =: фильтровать журналы по времени начала.
-U, –until =: фильтровать журналы по времени окончания.
–Disk-usage: показывает текущее использование диска всеми файлами логов.

3) Как использовать journalctl для чтения логов

Вы можете фильтровать логи в соответствии с вашими потребностями с помощью различных параметров и полей.

Мы покажем вам, как их использовать.

Просмотр основного журнала с помощью команды journalctl

Как вы заметили, в приведенном выше выводе логи показаны в хронологическом порядке.

Чтобы сначала отобразить последние логи, запустите команду journalctl с параметром «-r».

 sudo journalctl -n 20
-- Logs begin at Fri 2021-02-12 14:26:01 +0630, end at Fri 2021-03-19 13:24:41 +0630. --
Mar 19 12:01:01 DevSexOps run-parts(/etc/cron.hourly)[27459]: finished 0anacron
Mar 19 12:01:01 DevSexOps systemd[1]: Removed slice User Slice of root.
Mar 19 13:00:01 DevSexOps systemd[1]: Starting Docker Cleanup...
Mar 19 13:00:01 DevSexOps systemd[1]: Started Docker Cleanup.
Mar 19 13:01:01 DevSexOps systemd[1]: Created slice User Slice of root.
Mar 19 13:01:01 DevSexOps systemd[1]: Started Session 881 of user root.
Mar 19 13:01:01 DevSexOps CROND[30364]: (root) CMD (run-parts /etc/cron.hourly)
Mar 19 13:01:01 DevSexOps run-parts(/etc/cron.hourly)[30367]: starting 0anacron
Mar 19 13:01:01 DevSexOps run-parts(/etc/cron.hourly)[30373]: finished 0anacron
Mar 19 13:01:01 DevSexOps systemd[1]: Removed slice User Slice of root.
Mar 19 13:05:46 DevSexOps sshd[30600]: Accepted password for root from 10.2.67.11 port 64283 ssh2
Mar 19 13:05:46 DevSexOps systemd[1]: Created slice User Slice of root.
Mar 19 13:05:46 DevSexOps systemd-logind[752]: New session 882 of user root.
Mar 19 13:05:46 DevSexOps systemd[1]: Started Session 882 of user root.
Mar 19 13:05:46 DevSexOps sshd[30600]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 19 13:05:56 DevSexOps sudo[30634]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/journalctl
Mar 19 13:05:56 DevSexOps sudo[30634]: pam_unix(sudo:session): session opened for user root by root(uid=0)
Mar 19 13:24:39 DevSexOps sudo[30634]: pam_unix(sudo:session): session closed for user root
Mar 19 13:24:41 DevSexOps sudo[31542]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/journalctl -n 20
Mar 19 13:24:41 DevSexOps sudo[31542]: pam_unix(sudo:session): session opened for user root by root(uid=0)

Проверка логов в реальном времени

Логи в реальном времени можно просмотреть с помощью опции «-f», используя команду «journalctl», как показано ниже.

Это может быть полезно при устранении неполадок.

Фильтрация определенного лога загрузки

journalctl --list-boots
0 7ff1965b851448b3996046d8cefa4805 Fri 2021-02-12 14:26:01 +0630—Fri 2021-03-19 13:24:41 +0630

Журналы загрузки имеют префикс, начинающийся с нуля. «0» относится к текущей загрузке.

Сеанс загрузки «-1» – это последний загруженный сеанс и так далее.

Чтобы просмотреть сообщения из конкретной загрузки, выполните следующую команду.

Покажем все сообщения из текущей загрузки:

sudo journalctl -b
-- Logs begin at Fri 2021-02-12 14:26:01 +0630, end at Fri 2021-03-19 13:29:11 +0630. --
Feb 12 14:26:01 DevSexOps systemd-journal[97]: Runtime journal is using 8.0M (max allowed 189.4M, trying to leave 284.2M free of 1.8G available
Feb 12 14:26:01 DevSexOps kernel: Initializing cgroup subsys cpuset
Feb 12 14:26:01 DevSexOps kernel: Initializing cgroup subsys cpu
Feb 12 14:26:01 DevSexOps kernel: Initializing cgroup subsys cpuacct
Feb 12 14:26:01 DevSexOps kernel: Linux version 3.10.0-1160.15.2.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Re
Feb 12 14:26:01 DevSexOps kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-1160.15.2.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto
Feb 12 14:26:01 DevSexOps kernel: Disabled fast string operations
Feb 12 14:26:01 DevSexOps kernel: e820: BIOS-provided physical RAM map:
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f3ff] usable
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x000000000009f400-0x000000000009ffff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bfedffff] usable
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000bfee0000-0x00000000bfefefff] ACPI data
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000bfeff000-0x00000000bfefffff] ACPI NVS
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000bff00000-0x00000000bfffffff] usable
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x00000000fffe0000-0x00000000ffffffff] reserved
Feb 12 14:26:01 DevSexOps kernel: BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
Feb 12 14:26:01 DevSexOps kernel: NX (Execute Disable) protection: active
Feb 12 14:26:01 DevSexOps kernel: SMBIOS 2.7 present.
Feb 12 14:26:01 DevSexOps kernel: DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
Feb 12 14:26:01 DevSexOps kernel: Hypervisor detected: VMware
Feb 12 14:26:01 DevSexOps kernel: vmware: TSC freq read from hypervisor : 2194.843 MHz
Feb 12 14:26:01 DevSexOps kernel: vmware: Host bus clock speed read from hypervisor : 66000000 Hz
Feb 12 14:26:01 DevSexOps kernel: vmware: using sched offset of 7157487822 ns
Feb 12 14:26:01 DevSexOps kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Feb 12 14:26:01 DevSexOps kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Feb 12 14:26:01 DevSexOps kernel: e820: last_pfn = 0x140000 max_arch_pfn = 0x400000000
Feb 12 14:26:01 DevSexOps kernel: MTRR default type: uncachable
Feb 12 14:26:01 DevSexOps kernel: MTRR fixed ranges enabled:
Feb 12 14:26:01 DevSexOps kernel: 00000-9FFFF write-back
Feb 12 14:26:01 DevSexOps kernel: A0000-BFFFF uncachable
Feb 12 14:26:01 DevSexOps kernel: C0000-CFFFF write-protect
Feb 12 14:26:01 DevSexOps kernel: D0000-EFFFF uncachable
Feb 12 14:26:01 DevSexOps kernel: F0000-FFFFF write-protect
Feb 12 14:26:01 DevSexOps kernel: MTRR variable ranges enabled:

Чтобы проверить вывод сообщений предыдущего сеанса загрузки, выполните следующую команду:

Журналы журнала можно фильтровать по временному интервалу.

С фильтром времени можно использовать несколько аргументов, как показано ниже.

Чтобы использовать фильтр времени, используйте ключи командной строки ‘-S или –since’ и ‘-U или –until’.

Чтобы отфильтровать журналы со вчерашнего дня, выполните следующую команду:

$ sudo journalctl -S yesterday

Приоритет	Код
0	emerg
1	alert
2	crit
3	err
4	warning
5	notice
6	info
7	debug

$ sudo journalctl -p 3 -b
или
$ sudo journalctl -p err -b

Feb 12 14:26:02 DevSexOps kernel: sd 2:0:0:0: [sda] Assuming drive cache: write through
Feb 12 14:26:04 DevSexOps kernel: piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!
Feb 15 13:39:25 DevSexOps sudo[11546]: pam_unix(sudo-i:auth): conversation failed
Feb 15 13:39:25 DevSexOps sudo[11546]: pam_unix(sudo-i:auth): auth could not identify password for [user]
Feb 15 13:39:27 DevSexOps sudo[11546]: user : user NOT in sudoers ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Feb 15 13:46:54 DevSexOps sudo[11586]: pam_unix(sudo-i:auth): conversation failed
Feb 15 13:46:54 DevSexOps sudo[11586]: pam_unix(sudo-i:auth): auth could not identify password for [user]
Feb 15 13:46:56 DevSexOps sudo[11591]: pam_unix(sudo:auth): conversation failed
Feb 15 13:46:56 DevSexOps sudo[11591]: pam_unix(sudo:auth): auth could not identify password for [user]
Feb 15 13:46:56 DevSexOps sudo[11586]: user : user NOT in sudoers ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Feb 15 13:46:59 DevSexOps sudo[11589]: pam_unix(sudo-i:auth): conversation failed
Feb 15 13:46:59 DevSexOps sudo[11589]: pam_unix(sudo-i:auth): auth could not identify password for [user]
Feb 15 13:46:59 DevSexOps sudo[11591]: user : user NOT in sudoers ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/sh -c toilet -f bubble
Feb 15 13:47:01 DevSexOps sudo[11589]: user : user NOT in sudoers ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Feb 15 14:17:19 DevSexOps sudo[11936]: pam_unix(sudo-i:auth): conversation failed
Feb 15 14:17:19 DevSexOps sudo[11936]: pam_unix(sudo-i:auth): auth could not identify password for [user]
Feb 15 14:17:21 DevSexOps sudo[11938]: pam_unix(sudo:auth): conversation failed
Feb 15 14:17:21 DevSexOps sudo[11938]: pam_unix(sudo:auth): auth could not identify password for [user]
....

4) Фильтрация по полям

Логи можно фильтровать по определенным полям.

Синтаксис поля для сопоставления – «FIELD_NAME = MATCHED_VALUE», например «SYSTEMD_UNIT = httpd.service».

Кроме того, вы можете указать несколько совпадений в одном запросе для более удобной фильтрации.

Фильтрация по системному юниту

Чтобы показать логи, созданные указанной службой, используйте приведенные ниже команды.

Аналогичным образом вы можете фильтровать любые служебные сообщения.

Чтобы проверить доступные журналы служб, введите «journalctl -u» и дважды нажмите клавишу TAB.

$ sudo journalctl -u httpd.service
или
$ sudo journalctl _SYSTEMD_UNIT=httpd.service

Чтобы показать логи, созданные определенным идентификатором процесса, выполните следующую команду:

$ sudo journalctl _PID=1039

LOG и сообщения об ошибках.

Astra может записывать лог своей работы в следующие назначения:

console — если Astra запущена в интерактивном режиме, без опции — daemon
file —log /var/log/astra.log, где /var/log/astra.log полный путь к файлу журнала
syslog —syslog astra, где astra -имя процесса
web interface — отображение во вкладке LOG текущих системных сообщений

Сообщения в логе бывают следующих видов:

information
warning
error
debug

Описание ошибок и способы их устранения:

fe has lock

fe has lock. status:SCVYL signal:60% snr:80% ber:0 unc:0

Состояние адаптера DVB.
Описывается несколькими значениями:

status —список флагов, описывающих состояние тюнера. Состояние, если есть сигнал SCVYL:
- SIGNAL — появляется да же при незначительном уровне сигнала
- CARRIER — found a DVB signal
- VITERBI — FEC (forward error correction) is stable
- SYNC — found sync data
- LOCK — signal locked
- signal — уровень сигнала
- snr — отношение сигнал/шум
- ber — bit error rate. important for determining the reception quality
- unc — некоррекные блоки данных. также как ber, показывает качество приема

Too many open files

Ошибка возникает, если количество активных подключений или открытых файлов превышают ограничение операционной системы. Для проверки текущего лимита используйте следующую команду:

grep "open files" /proc/PID/limits

где PID — уникальный идентификатор процесса. Для его поиска — выполните: ps ax | grep astra

Чтобы изменить системный лимит, выполните команду ulimit -n 65536 и перезапустите Astra. Команда присутствует в скрипте запуска init.d

PAT: stream with id * is not found

Канал с указанным номером (pnr) в потоке не найден. Для проверки доступных каналов, необходимо просканировать источник.

Device or resource busy

Ошибка возникает при попытке использовать DVB адаптер, занятый другим процессом. Список адаптеров и их состояние можно проверить с помощью команды:
astra --dvbls
Пример вывода команды:.
Свободный адаптер:

Nov 10 09:00:00: INFO: adapter = 3, device = 0
Nov 10 09:00:00: INFO:     mac = 00:17:42:00:00:00
Nov 10 09:00:00: INFO:     frontend = Montage DS3103/TS2022
Nov 10 09:00:00: INFO:     type = S

Адаптер занят:

Nov 10 09:00:00: WARNING: adapter = 2, device = 0
Nov 10 09:00:00: WARNING:     adapter in use
Nov 10 09:00:00: WARNING:     mac = 00:17:42:54:09:52
Nov 10 09:00:00: WARNING:     frontend = Montage DS3103/TS2022
Nov 10 09:00:00: WARNING:     type = S

Ошибка при обращении к устройству. Возможно DVB адаптер неисправен, или вам нужно произвести переустановку драйвера:

Nov 10 09:00:00: ERROR: adapter = 1, device = 0
Nov 10 09:00:00: ERROR:     failed to open [Bad file descriptor]

Чтобы определить, какой процесс использует адаптер, используйте следующую команду:

lsof | grep adapterX | head -n1

замените X на номер адаптера.

Address already in use

Ошибка возникает при попытке использовать TCP-порт занятый другим процессом. Для просмотра списка открытых портов используйте команду:

netstat -tnlp

Resource temporarily unavailable

Сетевой адаптер не справляется с объемом данных, поступающих от Астры. Возможные причины:

Проверьте настройки сетевого буфера;
Проверьте режим работы сетевого адаптера: выполните команду ethtool eth* или mii-tool eth* . Скорость должна соответствовать типу адаптера 1Gbit, 10Gbit
Сетевой адаптер должен быть Intel или Broadcom
Проверьте настройки DVB-адаптеров и каналов. Если в настройках DVB адаптера установлен параметр budget=true, а в свойствах канала не указан номер канала (pnr), то будет передан весь транспондер

PES-Error

Ошибка в заголовке пакета с видео или аудио. Основные причины:

Неверный ключ дешифровки;
В случае приема потока от DVB адаптера необходимо проверить качество сигнала: astra --femon -a ADAPTER

CC-Error

CC-ошибка, увеличивается на 1 с каждым сбоем счетчика пакетов.
MPEG-TS поток разделяется на пакеты. Каждый пакет имеет номер со значением в диапазоне 0-15. Значение счетчика увеличивается с каждым пакетом и сбрасывается на 0 после 15 пакета.
Счетчик CC-ошибок увеличивается на 1 с каждым потерянным пакетом.

Возможные причины:

Потеря данных при приеме UDP/RTP. В Linux можно проверить с помощью команды netstat -su.
Если значение packet receive errors увеличивается, необходимо проверить настройки буфера сетевых соединений..
По возможности проведите диагностику на передающем сервере.
Слабый сигнал DVB или ошибки в сигнале. Необходимо проверить уровень сигнала и ошибки приема: astra –femon -a ADAPTER.
Дублирование потока при передаче по UDP. Несколько потоков имеют одинаковую группу мультикаста и номер порта.

Channel has no active inputs

Ошибка возникает, если канал не имеет доступных источников для переключения.
В настройках канала можно указать несколько источников (входов) для резервирования. Источники работают по порядку, в случае выхода из строя первого источника, происходит переключение на второй и так далее.
Ошибка возникает, если канал не имеет исправных доступных источников для переключения.
Причину сбоя источника можно определить по другим сообщениям в журнале, так как она является следствием ошибки, произошедшей ранее. Также можно проверить входящий поток с помощью анализатора потока: astra—analyze ADDRESS.

ECM Not Found

Не найден ключ для дешифрования потока. Возможная причина:

Нет подписки или подписка закончилась.
Неверный идентификатор пакета для пакетов ключей. При запуске канала, идентификатор пакета (PID) отображается в сообщении Select ECM pid:*. Идентификатор пакета можно выбрать вручную с помощью параметров ecm_pid или cas_data.
ecm_pid — устанавливает идентификатор пакета. Доступные идентификаторы отображаются в логе (сообщения Skip ECM pid:*).
cas_data — зависит от системы условного доступа.
Ограничение количества запросов сервера условного доступа или карты доступа.

Both keys changed

Нарушение последовательности ключей дешифровки. Обычно появляется после сообщения ECM Not Found.
Ключи для расшифровки потока передаются парами: current и next.
После смены ключа шифрования на следующий, приходит новая пара. Образец:

1111110022222200:33333300444444005555550066666600:
33333300444444005555550066666600:7777770088888800

Receiving timeout. restart input

В случае, если источник данных недоступен, происходит его перезапуск.
К примеру, если у нас есть сбой приема данных по протоколу http mpeg-ts и сервер закрыл соединение — произойдет попытка повторного подключения к нему.

Authentication failed

Ошибка авторизации при попытке доступа к Web-интерфейсу или API.
В лог выводится так же логин и IP адрес, с которым была попытка произвести авторизацию.

Event_request_send

Статус отправки данных на сервер мониторинга.
Если код ответа HTTP не 200 — то будет выведена ошибка.

Примеры:

failed 0:connection timeout
failed 400:Bad Request

Server limit

Возможно, ваша лицензия была скомпрометирована или вы превысили количество серверов в лицензии.
Свяжитесь со службой поддержки.

SDT checksum error

Ошибка проверки контрольной суммы таблицы SDT.
Обычно не приводит к проблемам с изображением.

Содержание

Исправление ошибок Linux
Решение проблем Linux
Проблемы с командами в терминале
Проблемы в программах
Проблемы с драйверами и ядром
Проблемы с графической оболочкой
Проблемы с диском и файловой системой
Выводы
Критическая ошибка смотрите лог файл или обратитесь к администратору astra linux как исправить
rsyslog
Ротация логов Linux
journald
Открытие бинарных файлов
Как определить и исправить проблемы с загрузкой в Linux
Краткое описание процесса загрузки Linux
Как определить проблемы загрузки Linux или сообщения об ошибках
/var/log/boot.log – регистрирует сообщения загрузки системы
/var/log/messages – Общие системные журналы
dmesg – Показывает сообщения ядра
journalctl – Содержимое журнала Systemd
Как использовать команду fsck для исправления ошибок файловой системы в Linux
Когда использовать fsck в Linux
Опции программы fsck
Как запустить fsck для исправления ошибок файловой системы Linux
Понимание кодов выхода fsck
Как исправить ошибки файловой системы Linux
Как запустить fsck на корневом разделе Linux
Как принудительно проверить диск с помощью fsck при загрузке системы
Как запустить fsck в режиме восстановления
Заключение

Исправление ошибок Linux

Каждый пользователь, рано или поздно сталкивается с определенными проблемами в своей операционной системе Linux. Это может быть просто неправильное использование команд или их непонимание, так и такие серьезные ошибки Linux, как отсутствие драйверов, неработоспособность сервисов зависание системы и так далее.

Эта статья ориентирована в первую очередь на новичков, которые не знают, что делать когда их будут поджидать проблемы linux, мы дадим общую концепцию и попытаемся показать в какую сторону двигаться дальше. Мы рассмотрим исправление ошибок в linux как простых, так и более сложных. Но давайте сначала определим, какие проблемы linux будем рассматривать, разобьем их на категории:

Все это мы рассмотрим ниже, но сначала общее введение и немного теории.

Решение проблем Linux

Linux очень сильно отличается от WIndows, это заметно также при возникновении проблем Linux. Вот допустим, произошла ошибка в программе Windows, она полностью закрывается или выдает непонятное число с кодом ошибки и все, вы можете только догадываться или использовать поиск Google, чтобы понять что произошло. Но в Linux все совсем по-другому. Здесь каждая программа создает лог файлы, в которых мы можем при достаточном знании английского или даже без него, выяснить, что произошло. Более того, если программу запускать из терминала, то все ошибки linux и предупреждения мы увидим прямо в окне терминала. и сразу можно понять что нужно делать.

Причем вы сможете понять что произошло, даже не зная английского. Главным признаком ошибки есть слово ERROR (ошибка) или WARNING (предупреждение). Рассмотрим самые частые сообщения об ошибках:

Сообщения об ошибках, кроме терминала, мы можем найти в различных лог файлах, все они находятся в папке /var/log, мы рассматривали за какие программы отвечают определенные файлы в статье просмотр логов linux. Теперь же мы подробнее рассмотрим где и что искать если linux выдает ошибку.

Проблемы с командами в терминале

Обычно проблемы с командами в терминале возникают не из-за ошибки linux или потому, что разработчики что-то недоработали, а потому, что вы ввели что-то неправильно или предали не те что нужно опции.

Если были переданы не те опции, то, скорее всего, программа покажет вам справку, ознакомившись с которой вы сможете очень быстро понять в чем проблема. Также справку выдают множество команд если их запустить без параметров.

Если файла, которого вы передали в параметрах не существует, то вам будет об этом сказано соответствующим сообщением. Сообщения могут быть и более специфичные, в зависимости от ошибки, но в конце концов, вы можете воспользоваться переводчиком Google, чтобы понять смысл того, что хочет система.

Очень распространенной среди новичков ошибкой, есть no such file or directory при попытке выполнить файл, скачанный из интернета. Сразу кажется что это бред, ведь файл существует, но на самом деле оболочка ищет только файлы с флагом исполняемый, а поэтому пока вы не установите этот флаг для файла, он для оболочки существовать не будет.

Проблемы в программах

Если ни с того ни с сего закрывается или не так, как требуется работает, какая-нибудь графическая программа, решение проблем linux начинается из запуска ее через терминал. Для этого просто введите исполняемый файл программы и нажмите Enter. Обычно достаточно начать вводить имя программы с маленькой буквы и использовать автодополнение для завершения ввода названия.

Многие ошибки системы linux, связанные с графической оболочкой вы можете найти в файле

/.xsession-errors в вашей домашней директории. Если оболочка работает медленно, зависает или не работают другие программы, но в других логах причин этому нет, возможно, ответ находится именно в этом файле.

Также ошибки linux могут возникать не только в обычных программах но и в работающих в фоне сервисах. Но их тоже можно решить, чтобы посмотреть сообщения, генерируемые сервисом, запущенным с помощью systemd, просто наберите команду просмотра состояния сервиса:

$ sudo systemctl status имя_сервиса

Дальше вы знаете, что делать с этой ошибкой, главное что у вас есть зацепка, а дальше все можно решить, ну или почти все.

Здесь, как и всегда большинство ошибок связано с тем, что что-то не установлено, какого-то файла нет или к чему-то невозможно получить доступ, тогда решение проблем linux не вызовет много забот.

Проблемы с драйверами и ядром

Проблемы с драйверами, модулями ядра или прошивками могут вызвать много неприятностей во время загрузки системы. Это может быть просто медленная загрузка системы, неработоспособность определенных устройств неправильная работа видео или полная невозможность запустить графическую подсистему. Исправление ошибок Linux начинается с просмотра логов.

Вы можете посмотреть все сообщения ядра с момента начала загрузки, выполнив команду чтобы узнать какую linux выдает ошибку:

Чтобы иметь возможность удобно листать вывод можно выполнить:

Или сразу выбрать все ошибки:

sudo dmesg | grep error

Дальше будет очень просто понять какого драйвера не хватает, что система не может загрузить или что нужно установить. Если возникает ошибка ввода-вывода linux, то, скорее всего, драйвер несовместим с вашим устройством, в таком случае, может помочь обновление ядра, чтобы получить самую новую версию драйвера. В некоторых случаях ядро может само предложить вариант решения проблемы прямо в сообщении об ошибке вплоть до того какую команду выполнить или какой файл скачать. Если же нет, вы все еще можете воспользоваться поиском для решения своей проблемы linux.

Проблемы с графической оболочкой

Когда проблемы linux касаются графической оболочки, то решить их новичкам не так уж просто. Больше всего потому что доступен только терминал. Графическая оболочка может просто зависнуть или вовсе не запускаться, например, после обновления.

При проблемах с графической оболочкой вы можете всегда переключиться в режим терминала с помощью сочетания клавиш Ctrl+Alt+F1. Далее, вам нужно ввести логин и пароль, затем можете вводить команды терминала.

Посмотреть логи графической оболочки вы можете в том же файле

Если проблема наблюдается после обновления до новой версии, то можно очистить кеш и удалить папку с настройками, обычно это помогает.

Проблемы с диском и файловой системой

Если это случилось, вам, скорее всего, придется переключиться в режим терминала и удалить несколько файлов. Вы можете удалять файлы логов или кэша пакетного менеджера. Много файлов удалять не нужно, достаточно освободить несколько мегабайт, чтобы прекратились ошибки системы linux и нормально работала графическая оболочка, а затем уже в ней решать все проблемы linux.

Выводы

Теперь исправление ошибок Linux будет для вас немного проще. Ошибки системы linux довольно сложная тема и этой информации явно мало, если у вас остались вопросы или есть предложения по улучшению статьи пишите в комментариях!

Источник

Критическая ошибка смотрите лог файл или обратитесь к администратору astra linux как исправить

rsyslog

Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:

В этом файле также фиксируется выполнение команд с повышенными правами.

4 sudo

Откроем файл /var/log/syslog

На скриншоте выделено сообщение о выключении сетевого интерфейса.

grep ‘pptpd’ /var/log/syslog

Ротация логов Linux

Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.

В начале правила указывается путь к файлу журнала, затем в фигурных скобках перечисляются директивы.

Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”

journald

Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd

11 sudo

Для того, чтобы узнать сколько места на диске занимают файлы журнала, выполним команду

Для ограничения объема журнала размером 1Gb выполним команду

Открытие бинарных файлов

12 last

Источник

Как определить и исправить проблемы с загрузкой в Linux

1 10

Система Linux загружается так быстро, что большая часть вывода слишком быстро прокручивается, чтобы прочитать текст (показывая запущенные службы), отправленные на консоль.

Поэтому наблюдение за проблемами загрузки / ошибками становится для нас проблемой.

В этой статье мы кратко объясним различные этапы процесса загрузки системы Linux, а затем узнаем, как установить и решить проблемы с загрузкой.

Краткое описание процесса загрузки Linux

Итак, как только мы нажмем кнопку Power On, BIOS (Basic Input Output System), программа встроенная в материнскую плату, выполняет POST (Power on Self Test) – где такие аппаратные средства, как диски, оперативная память (Random Access Memory), клавиатура, и т. д. сканируются.

В случае ошибки (отсутствие / неисправное оборудование), это сообщается на экране.

Во время POST BIOS также ищет загрузочное устройство, на котором установлен диск (обычно первый жесткий диск, однако мы можем настроить его как DVD, USB, сетевую карту и т. д).

Затем система подключится к диску и выполнит поиск основной загрузочной записи (размером 512 байт), в которой хранится загрузчик (размер 446 байт), а остальная часть пространства хранит информацию о дисковых разделах (четыре максимум) и MBR.

Загрузчик будет идентифицировать и указывать на него, а также загружать ядро и файл initrd (диск с инициализацией) – который обеспечивает доступ ядра к установленной корневой файловой системе и модулям / драйверам, хранящимся в каталоге / lib), которые обычно хранятся в каталоге /boot файловой системы.

После загрузки ядра он запускает init (или systemd на более новых дистрибутивах Linux), первый процесс с PID 1, который, в свою очередь, запускает все остальные процессы в системе.

Это также последний процесс, который должен быть выполнен при завершении работы системы.

Как определить проблемы загрузки Linux или сообщения об ошибках

Как уже упоминалось ранее, процессы загрузки Linux происходят быстро, и мы не можем даже четко прочитать большую часть вывода, отправленного на консоль.

Поэтому, принимая во внимание проблемы с загрузкой / ошибки, администратор системы обращается к некоторым важным файлам определенными командами.

/var/log/boot.log – регистрирует сообщения загрузки системы

Это, вероятно, первый файл, который вам надо изучить, чтобы просмотреть все, что было во время загрузки системы.

Вместо того, чтобы так пристально следить за выводом на экране во время загрузки, мы можем просмотреть этот файл после завершения процесса загрузки, чтобы помочь нам в определении и устранении проблем / ошибок загрузки.

Мы используем команду cat для этой задачи следующим образом (ниже приведен пример этого файла):

Из вышеприведенного вывода видно, что проблемы с загрузкой существуют и указаны отдельно ниже:

Проблема: проблема с разделом подкачки; система либо не прочитала файл подкачки / устройство / раздел, либо его нет.

Давайте проверим, использует ли система пространство подкачки с командой free.

Кроме того, мы можем запустить команду swapon, чтобы просмотреть сводку использования пространства подкачки системы (мы не получим никакого вывода).

Мы можем решить эту проблему, создав пространство подкачки в Linux.

Примечание. Содержимое этого файла очищается при завершении работы системы: новые данные хранятся в нем при новой загрузке.

/var/log/messages – Общие системные журналы

В этом файле хранятся общие системные сообщения, в том числе сообщения, которые регистрируются во время загрузки системы.

Чтобы просмотреть его, введите:

Поскольку этот файл может быть относительно длинным, мы можем просмотреть его постранично, используя команду more (которая даже показывает проценты):

Содержимое /var/log/messages, в отличие от предыдущего файла, не очищается, так как оно содержит не только загрузочные сообщения, но и сообщения о других действиях системы.

Поэтому старые файлы сжимаются и сохраняются в системе для последующей проверки, как показано ниже.

dmesg – Показывает сообщения ядра

Команда dmesg может показывать операции после завершения процесса загрузки, такие как параметры командной строки, переданные ядру; обнаруженные аппаратные компоненты, события при добавлении нового USB-устройства или ошибки, такие как сбои сетевого адаптера (Network Interface Card), что драйверы не сообщают о активности канала в сети и о многом другом.

journalctl – Содержимое журнала Systemd

Эти сообщения включают сообщения ядра и загрузки; сообщения из syslog или различных служб.

Мы можем использовать его для просмотра загрузочных сообщений и установления проблем с загрузкой путем чтения результатов и определения интересующих строк (ошибки, отмеченные красными линиями в зависимости от настроек цвета текста терминала).

Вышеприведенный пример вывода команды показывает ошибку, которую мы уже идентифицировали, просмотрев /var/log/boot.log: ошибка раздела подкачки.

Чтобы просмотреть больше выходных строк, просто нажмите кнопку [Ввод].

Источник

Как использовать команду fsck для исправления ошибок файловой системы в Linux

Файловые системы отвечают за организацию хранения и восстановления данных. Так или иначе, со временем файловая система может быть повреждена, и некоторые её части могут оказаться недоступными. Если ваша файловая система обнаруживает такую несогласованность, рекомендуется проверить её целостность.

Это можно сделать с помощью системной утилиты fsck (проверка целостности файловой системы). Эта проверка может выполняться автоматически во время загрузки или запускаться вручную.

В этой статье мы рассмотрим утилиту fsck и её использование, чтобы помочь вам исправить ошибки диска.

Когда использовать fsck в Linux

Есть разные сценарии, когда вы захотите запустить fsck. Вот несколько примеров:

Опции программы fsck

Команду fsck необходимо запускать с привилегиями суперпользователя или root. Вы можете использовать её с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:

Как запустить fsck для исправления ошибок файловой системы Linux

Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для целей этой статьи я буду использовать свой второй диск /dev/sda, смонтированный в /mnt/disk_d.

Вот что произойдёт, если я попытаюсь запустить fsck, когда раздел смонтирован.

fsck

Если диск не только смонтирован, но и используется (например, диск, смонтированный в корневую файловую систему), то ошибка будет «/dev/nvme0n1 is in use».

Чтобы избежать этого, отключите раздел с помощью следующей команды (замените имя диска на ваше):

Тогда можно будет безопасно запускать fsck.

fsck 2

Понимание кодов выхода fsck

После запуска fsck он вернёт код выхода. Эти коды можно увидеть в руководстве по fsck, запустив:

Описание кодов выхода fsck:

Как исправить ошибки файловой системы Linux

Иногда в файловой системе может быть обнаружено более одной ошибки. В таких случаях вы можете захотеть, чтобы fsck автоматически пытался исправить ошибки. Это можно сделать с помощью:

Флаг -y означает автоматически отвечать «да» на любые запросы от fsck для исправления ошибки.

Точно так же вы можете запустить то же самое во всех файловых системах (с пропуском корневой файловой системы):

Как запустить fsck на корневом разделе Linux

В некоторых случаях вам может потребоваться запустить fsck в корневом разделе вашей системы. Поскольку вы не можете запустить fsck, пока раздел смонтирован, вы можете попробовать один из следующих вариантов:

Мы рассмотрим обе ситуации.

Как принудительно проверить диск с помощью fsck при загрузке системы

Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:

Затем вы можете просто принудительно перезагрузить или запланировать перезагрузку системы. Во время следующей загрузки будет выполнена проверка диска командой fsck. Если время простоя критично, рекомендуется тщательно его спланировать, поскольку, если в вашей системе много используемых inode, выполнение fsck может занять дополнительное время.

После загрузки системы проверьте, существует ли ещё файл:

Если это так, вы можете удалить его, чтобы избежать появления fsck при каждой загрузке системы.

Как запустить fsck в режиме восстановления

Для запуска fsck в режиме восстановления требуется ещё несколько шагов. Сначала подготовьте вашу систему к перезагрузке. Остановите все критически важные службы, такие как MySQL/MariaDB и т. д., а затем введите.

Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите Advanced options («Дополнительные параметры»).

Затем выберите Recovery mode («Режим восстановления»).

В следующем меню выберите «fsck».

Вас спросят, хотите ли вы перемонтировать / файловую систему. Выберите Yes («да»).

Вы должны увидеть нечто подобное.

Затем вы можете вернуться к нормальной загрузке, выбрав Resume («Возобновить»).

Заключение

В этом руководстве вы узнали, как использовать fsck и выполнять проверки согласованности в разных файловых системах Linux. Если у вас есть какие-либо вопросы о fsck, не стесняйтесь задавать их в разделе комментариев ниже.

Источник

Анализ логов является важной задачей системного администратора. Если что-то идет не так в системе Linux, ответ часто находится в логах. На CentOS 7 две разные системы логирования используются бок о бок, и важно знать, как и где найти информацию. Эта статья научит вас всему этому. Вы узнаете, как читать логи, настраивать rsyslogd и journald, а также как настроить свою систему на ротацию логов, чтобы предотвратить полное заполнение дисков службами, которые регистрируют события в этих самых логах.

Понимание логирования

Большинство сервисов, используемых на сервере Linux, записывают информацию в лог-файлы. Эта информация может быть записана в разных местах, и существует несколько решений для поиска соответствующей информации в системных логах. Сервисы могут использовать не менее трех разных подходов для записи информации в логи:

Прямая запись: некоторые сервисы записывают информацию напрямую в лог-файлы, даже некоторые важные сервисы, такие как веб-сервер Apache и файловый сервер Samba.
rsyslogd: rsyslogd — это усовершенствование сервиса syslogd, который занимается централизованным управлением лог-файлов. Syslogd существует уже давно.
journald: с введением systemd также был представлен сервис логирования journald. Этот сервис тесно интегрирован с systemd, что позволяет администраторам читать подробную информацию из journald, одновременно отслеживая состояние сервиса с помощью команды systemctl status.

Понимание ролей rsyslogd и journald

journald (который реализуется демоном systemd-journald) предоставляет усовершенствованную систему управления логами. journald собирает сообщения из ядра, всей процедуры загрузки и сервисов и записывает эти сообщения в журнал событий. Этот журнал событий хранится в двоичном формате, и его можно запросить с помощью команды journalctl.

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

rsyslogd предлагает функции, которых нет в journald, такие как централизованное ведение журнала и фильтрация сообщений с использованием модулей. В текущем состоянии journald не является заменой rsyslogd; это просто еще один способ регистрации информации. journald тесно интегрирован с systemd и поэтому регистрирует всё, что делает ваш сервер. rsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.

Чтобы получить больше информации о том, что происходит на машине, администраторы должны использовать три подхода:

Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
Команда journalctl может использоваться для получения более подробной информации из журнала.
Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status <unit>. Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

[root@server1 ~]# systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: failed (Result: exit-code) since Fri 2019-10-25 05:25:18
PDT; 2s ago
Process: 2893 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=0/SUCCESS)
Process: 2890 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
Main PID: 2890 (code=exited, status=1/FAILURE)
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address [::]:443
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address 0.0.0.0:443
Oct 25 05:25:18 server1.example.com httpd[2890]: no listening sockets
available, shutting down
Oct 25 05:25:18 server1.example.com httpd[2890]: AH00015: Unable to
open logs
Oct 25 05:25:18 server1.example.com systemd[1]: httpd.service: main
process exited, code=exited, status=1/FAILURE
Oct 25 05:25:18 server1.example.com systemd[1]: Failed to start The
Apache HTTP Server.
Oct 25 05:25:18 server1.example.com systemd[1]: Unit httpd.service
entered failed state.

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

Точное количество файлов в каталоге /var/log будет меняться в зависимости от конфигурации сервера и сервисов, работающих на этом сервере. Однако некоторые файлы существуют в большинстве случаев, и, как администратор, вы должны знать, какие это файлы и какое содержимое можно ожидать в этих файлах.

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

log-файл	Объяснение
/var/log/messages	Наиболее часто используемый файл журнала, это общий файл журнала, в который записывается большинство сообщений.
/var/log/dmesg	Содержит сообщения журнала ядра.
/var/log/secure	Содержит сообщения, связанные с аутентификацией.
/var/log/boot.log	Сообщения, связанные с запуском системы.
/var/log/audit/audit.log	Содержит сообщения аудита. SELinux пишет в этот файл.
/var/log/maillog	Сообщения, связанные с почтой.
/var/log/samba	Предоставляет файлы журналов для сервиса Samba. Обратите внимание, что по умолчанию Samba не управляется через rsyslog, а записывается непосредственно в каталог /var/log.
/var/log/sssd	Содержит сообщения, записанные сервисом sssd, который играет важную роль в процессе аутентификации.
/var/log/cups	Содержит сообщения, сгенерированные службой печати CUPS.
/var/log/httpd/	Каталог, содержащий лог-файлы, которые записываются веб-сервером Apache. Обратите внимание, что Apache пишет сообщения в эти файлы напрямую, а не через rsyslog.

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2

[root@kvm ~]# tail -n 20 /var/log/messages
Oct 31 22:05:56 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:06:09 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 15 (xid=0x278ccc34)
Oct 31 22:06:24 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 16 (xid=0x278ccc34)
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5185] dhcp4 (em1):request timed out
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5186] dhcp4 (em1):state changed unknown -> timeout
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):canceled DHCP transaction, DHCP client pid 24837
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):state changed timeout -> done
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5274] device (em1): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5284] device (em1): Activation: failed for connection 'Wired connection 1'
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5288] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm avahi-daemon[2499]: Withdrawing address record for fe80::6bbe:cb13:850c:d799 on em1.
Oct 31 22:06:41 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:10:01 kvm systemd: Created slice User Slice of root.
Oct 31 22:10:01 kvm systemd: Started Session 413 of user root.
Oct 31 22:10:01 kvm systemd: Removed slice User Slice of root.
Oct 31 22:10:08 kvm systemd-logind: New session 414 of user admin.
Oct 31 22:10:08 kvm systemd: Started Session 414 of user admin.
Oct 31 22:10:08 kvm dbus[2512]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Oct 31 22:10:08 kvm dbus[2512]: [system] Successfully activated service 'org.freedesktop.problems'
Oct 31 22:10:15 kvm su: (to root) admin on pts/11

Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
Хост: хост, с которого отправлено сообщение. Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

Чтобы убедиться, что информация, которая должна быть залогирована, записана в то место, где вы хотите ее найти, вы можете настроить сервис rsyslogd в файле /etc/rsyslog.conf. В этом файле вы найдете различные разделы, которые позволяют указать, где и как должна быть записана информация.

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

Объекты, приоритеты, и места назначения

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

■ Приоритет используется для определения серьезности сообщения, которое необходимо залогировать.
При указании приоритета по умолчанию с таким приоритетом логируются все сообщения, а так же все сообщения с приоритетом выше текущего.

■ Назначение определяет, куда должно быть записано сообщение. Типичными адресатами являются файлы, но модули rsyslog также могут использоваться в качестве места назначения для дальнейшей обработки через модуль rsyslogd.

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

В листинге 3 вы можете увидеть, как различные объекты и приоритеты используются для определения местоположений, в которые можно логировать информацию. Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объект	Что логируется
auth / authpriv	Сообщения, связанные с аутентификацией.
cron	Сообщения, сгенерированные сервисом crond.
daemon	Универсальный объект, который можно использовать для неопределенных демонов.
kern	Сообщения ядра.
lpr	Сообщения, сгенерированные через систему печати.
mail	Сообщения, связанные с электронной почтой.
mark	Специальный объект, который можно использовать для периодической записи маркера.
news	Сообщения, генерируемые системой новостей NNTP.
security	То же, что и auth / authpriv. Не должен больше использоваться.
syslog	Сообщения, генерируемые системой syslog.
user	Сообщения генерируемые в пространстве пользователя.
uucp	Сообщения, сгенерированные устаревшей системой UUCP.
local0-7	Резервные объекты, которые необходимы для использования тех объектов, которые отсутствуют в этой таблице.

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

Чтобы определить, какие типы сообщений должны логироваться, в строках rsyslog.conf могут использоваться разные уровни серьезности. Эти серьезности являются syslog-приоритетами. В таблице 3 представлен обзор доступных приоритетов в порядке возрастания.

Таблица 3

Приоритет	Используется для
debug	Отладочные сообщения, которые дадут как можно больше информации о работе сервиса.
info	Информационные сообщения о нормальной работе сервиса.
notice	Используется для информационных сообщений об элементах, которые позже могут стать проблемой.
warning / warn	Что-то не оптимальное, но ошибки пока нет.
err /error	Произошла некритическая ошибка.
crit	Произошла критическая ошибка.
alert	Используется, когда сервис перестал быть доступен.
emerg / panic	Сообщение генерируется, когда доступность сервиса прекращается.

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug. Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска).

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

cron.=debug                     -/var/log/cron.debug

Нет необходимости учить наизусть названия rsyslogd объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:

ErrorLog    syslog:local1

3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:

local1:error                    -/var/log/httpd-error.log

5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

Ротация лог-файлов

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

ВНИМАНИЕ! Лог-файлы, которые были ротированы, нигде не хранятся; они просто исчезают. Если политика вашей компании требует от вас доступа к информации о событиях, которые произошли более 5 недель назад, вам следует принять меры. Вы можете либо создать резервную копию лог-файлов, либо настроить сервер логов, где logrotate хранит ротированные сообщения в течение значительно более длительного периода.

Настройки по умолчанию для ротации логов хранятся в файле /etc/logrotate.conf

[root@kvm ~]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
[root@kvm ~]#

Наиболее важные настройки, используемые в этом файле конфигурации, заставляют logrotate еженедельно ротировать файлы и сохранять четыре старые версии файла. Вы можете получить больше информации о других параметрах в этом файле с помощью команды man logrotate.

Если для определенных файлов требуются определенные настройки, вы можете создать файл конфигурации для этого файла в /etc/logrotate.d. Настройки для этого файла перезаписывают настройки по умолчанию в /etc/logrotate.conf.

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

Самый простой способ использовать journalctl — просто набрать команду. Он показывает последние события, которые были записаны в журнал с момента последнего запуска вашего сервера. Обратите внимание, что результат этой команды отображается в меньшем количестве страниц, и по умолчанию вы увидите начало журнала.

Поскольку журнал записывается с момента загрузки сервера, в нем отображаются сообщения журнала, связанные с загрузкой. Если вы хотите просмотреть последние сообщения, которые были зарегистрированы, вы можете использовать journalctl -f, который показывает последние строки сообщений, в которые автоматически добавляются новые строки журнала.

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4

Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5648] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5652] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5672] dhcp4 (em2): dhclient started with pid 23750
Nov 03 13:39:03 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:39:03 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 7 (xid=0x48a6ece5)
Nov 03 13:39:10 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 12 (xid=0x48a6ece5)
Nov 03 13:39:18 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:39:22 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 20 (xid=0x48a6ece5)
Nov 03 13:39:42 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 18 (xid=0x48a6ece5)
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5190] dhcp4 (em2): request timed out
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5191] dhcp4 (em2): state changed unknown -> timeout
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): canceled DHCP transaction, DHCP client pid 23750
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): state changed timeout -> done
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5284] device (em2): state change: ip-config -> failed (reason 'ip-config-
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5291] device (em2): Activation: failed for connection 'Wired connection 2
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5295] device (em2): state change: failed -> disconnected (reason 'none',
Nov 03 13:39:48 kvm avahi-daemon[2499]: Withdrawing address record for fe80::8cce:3bf7:7f8b:9335 on em2.
Nov 03 13:40:01 kvm systemd[1]: Created slice User Slice of root.
Nov 03 13:40:01 kvm systemd[1]: Started Session 867 of user root.
Nov 03 13:40:01 kvm CROND[23918]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Nov 03 13:40:01 kvm systemd[1]: Removed slice User Slice of root.
Nov 03 13:40:03 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.145 52:54:00:66:3d:c4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.145 52:54:00:66:3d:c4 server2
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6056] policy: auto-activating connection 'Wired connection 2' (17698f02-4
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6067] device (em2): Activation: starting connection 'Wired connection 2'
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6068] device (em2): state change: disconnected -> prepare (reason 'none',
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6073] device (em2): state change: prepare -> config (reason 'none', sys-i
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6339] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6347] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6396] dhcp4 (em2): dhclient started with pid 24344
Nov 03 13:44:48 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:44:48 kvm dhclient[24344]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 (xid=0x4c41d823)

Что делает journalctl гибкой командой, так это то, что ее многочисленные опции фильтрации позволяют вам показать именно то, что вам нужно. Упражнение 3 показывает некоторые из наиболее интересных вариантов.

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

1. Введите journalctl. Вы увидите содержимое журнала с момента последнего запуска сервера, начиная с начала журнала. Содержимое отображается в меньшем количестве, поэтому вы можете использовать, например, less для просмотра файла.

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

В предыдущем упражнении вы ввели journalctl -o verbose, чтобы показать подробный вывод.
В листинге 5 приведен пример подробного вывода. Вы можете увидеть, что вывод предоставляет подробную информацию для всех элементов, которые были логированы, в том числе PID, идентификатор связанный с учетной записью пользователя и группы и многое другое.

Листинг 5

[root@kvm ~]# journalctl -o verbose
-- Logs begin at Tue 2019-10-29 13:15:14 +10, end at Sun 2019-11-03 14:04:03 +10. --
Tue 2019-10-29 13:15:14.573354 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=1;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d0a;t=596040660742a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 8.0M (max allowed 2.3G, trying to leave 3.5G free of 23.5G available → current limit 2.3G).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
    _PID=184
    _UID=0
    _GID=0
    _COMM=systemd-journal
    _EXE=/usr/lib/systemd/systemd-journald
    _CMDLINE=/usr/lib/systemd/systemd-journald
    _CAP_EFFECTIVE=5402800cf
    _SYSTEMD_CGROUP=/system.slice/systemd-journald.service
    _SYSTEMD_UNIT=systemd-journald.service
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
Tue 2019-10-29 13:15:14.573478 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=2;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d85;t=59604066074a6;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    MESSAGE=microcode: microcode updated early to revision 0x1d, date = 2018-05-11
Tue 2019-10-29 13:15:14.573513 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=3;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104da8;t=59604066074c9;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0

Сохранение журнала systemd

По умолчанию журнал хранится в файле /run/log/journal. Весь каталог /run используется только для информации о текущем состоянии процесса, что означает, что журнал очищается при перезагрузке системы. Чтобы сделать журнал постоянным между перезагрузками системы, вы должны убедиться, что существует каталог /var/log/journal.

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Листинг 6

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.

Рекомендую прочитать «Логи в Linux часть 2. Расширенные функции логов».

Источник

Далее на определенные объекты можно ссылаться по его идентификатору, например в определении объекта «путь»:

Параметры объектов могут иметь обязательные и необязательные опции. Обязательные опции являются позиционными и должны быть указаны в заданном порядке. Необязательные опции имеют формат
() и могут указываться в любом порядке.

Тот же пример определения простого пути с использованием inline-определений источника и приемника:

Таблица 1. Драйверы источников

Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS..

Таблица 2. Драйверы приемников

Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версия 2 и новее.

Таблица 3. Доступные фильтры.

Подробное описание см. man logrotate.

Взаимная замена служб rsyslog/syslog-ng

Замена пакетов

остановка заменяемой службы;
удаление пакета, предоставляющего удаляемую службу;
установка пакета с новой службой.

Миграция конфигурационных файлов

Для проверки синтаксической корректности конфигурационных файлов службы syslog-ng можно использовать команду:

Далее в качестве примера приведено соответствие конфигураций rsyslog и syslog-ng некоторых пакетов. :

# Log cloudinit generated log messages to file :syslogtag, isequal, "[CLOUDINIT]" /var/log/cloud-init.log # comment out the following line to allow CLOUDINIT messages through. # Doing so means you'll also get CLOUDINIT messages in /var/log/syslog & stop

log < source(s_src); filter < message("^.*CLOUDINIT.*$"); >; destination < file("/var/log/cloud-init.log"); >; flags( final); >;

# Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile :programname, startswith, "haproxy" < /var/log/haproxy.log stop >

log < source < unix-dgram("/var/lib/haproxy/dev/log"); >; filter < program("haproxy"); >; destination < file("/var/log/haproxy.log"); >; flags( final); >;

# Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& stop

log < source(s_src); filter < message("^.*UFW.*$"); >; destination < file("/var/log/ufw.log"); >; # flags( final); >;

# Send Jetty messages to jetty.out when using systemd :programname, startswith, "jetty9" < /var/log/jetty9/jetty-console.log stop >

log < source(s_src); filter < program("jetty9"); >; destination < file("/var/log/jetty9/jetty-console.log"); >; flags( final); >;

# Create an additional socket in postfix's chroot in order not to break # mail logging when rsyslog is restarted. If the directory is missing, # rsyslog will silently skip creating the socket. $AddUnixListenSocket /var/spool/postfix/dev/log

log < source < unix-stream("/var/spool/postfix/dev/log" keep-alive(yes)); >; filter < program("postfix"); >; destination(d_syslog); >;

# Send Tomcat messages to catalina.out when using systemd $template TomcatFormat, "[%timegenerated. date-year%- %timegenerated. date-month%- %timegenerated. date-day% %timegenerated. date-hour%: %timegenerated. date-minute%: %timegenerated. date-second%] [%syslogseverity-text%]%msg%\n" :programname, startswith, "tomcat9" < /var/log/tomcat9/catalina.out;TomcatFormat stop >

log < source(s_src); filter < program("tomcat9"); >; destination < file("/var/log/tomcat9/catalina.out", template("[$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC] [$PRIORITY]$MSG\n")); >; flags( final); >;

Инструмент сбора журналов astra-create-debug-logs

Расположение файлов журналов основных системных служб

Необходимо включить запись в журнал в конфигурационном файле /etc/dovecot/conf.d/10-logging.conf в параметре log_path.
Например, указать: /var/log/dovecot.log

Источник

Настройка аудита

Все факты начала и окончания работы пользователя фиксируется в журнале /var/log/auth.log на клиентской машине. Например:

Feb 19 12:32:48 nd-nout fly-dm: :0[3421]: pam_unix(fly-dm:session): session opened for user ivanov by (uid=0)

Указанная запись содержит информацию о начале сессии для пользователя с учетной записью « ivanov ».

Указанная запись содержит информацию о завершении сессии для пользователя с учетной записью « petrovich ».

Кроме того, информация о начале и завершении работы пользователя попадает в журнал подсистемы безопасности parsec: /var/log/parsec/user.mlog , доступный для просмотра при помощи утилиты « userlog ». В журнале регистрируются события с типами « auth » (вход), « exit » (выход).

[u] ‘Tue Feb 19 12:50:00 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 12:57:59 2013’ ‘/usr/bin/fly-dm’ [s] exit(«fly-dm»,»root»)

[u] ‘Tue Feb 19 13:14:52 2013’ ‘/bin/login’ [s] auth(«login»,»root»)

[u] ‘Tue Feb 19 13:15:33 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:15:39 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:19:53 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:20:13 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:20:23 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:20:31 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:27:48 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:27:54 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:33:51 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:33:55 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:39:49 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

[u] ‘Tue Feb 19 13:39:53 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

Описание системы регистрации событий приведено в разделе 10 документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1». Дополнительная информация приведена на страницах справочного руководства « man » для расширенной системы протоколирования, доступной по команде « man parselog ». В операционной системе специального назначения «Astra Linux Special Edition» обеспечивается регистрация всех событий в соответствии с требованиями документа «Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» ФСТЭК России, предъявляемых к средствам вычислительной техники третьего класса защищенности. Регистрация событий может быть проверена следующим образом: устанавливаем для пользователя (доменного) все возможные флаги аудита:

Audit policy user:petrovich

Audit success rules: ocxudntligarmphew

Источник

Время на прочтение
6 мин

Количество просмотров 427K

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

приложения;
события;
службы;
системный.

Большинство же лог файлов содержится в директории /var/log.

/var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
/var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
/var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

/var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
/var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
/var/log/audit — Записи, созданные службой аудита auditd.
/var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
/var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
/var/log/cups — Все, что связано с печатью и принтерами.
/var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
/var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
/var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
/var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
/var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
/var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

/var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
/var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
/var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

/var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
/var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
/var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
/var/log/utmp — Список входов пользователей в систему на данный момент.
/var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]

И другие журналы

Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.

/var/log/mysql/ — Лог базы данных MySQL.
/var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
/var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.

Access_log веб сервера.
CUPS page_log
Syslog
glog
dpkg.log
strace
Произвольные записи с временными отметками
gzip, bzip
Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>. Это с моего syslog-а.

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

Использованные материалы

lnav — An Advanced Log File viewer for Linux
What Are Linux Logs? How to View Them, Most Important Directories, and More
Как посмотреть логи в Linux

Источник