Как посмотреть текущий вывод задачи, которую выполняет cron?
Добавить в команду крона вконце > /var/log/tut_imya_loga.log 2>&1 и смотреть его через tail -f — не вариант?
14 ноя 2017 в 7:23
@nobody похоже tail то, что надо. Спасибо. А > /var/log/tut_imya_loga.log 2>&1 будет каждый раз заново перезаписывать файл или в конец писать?
14 ноя 2017 в 7:31
Я одного не пойму — а почему нельзя в этих задачах использовать нормальный вывод в syslog ? Тогда бы все проблеммы были сразу решены. Или исходные тексты задачи отсутствуют? В том варианте, что предложил nobody, если запущено несколько задач, то они буду затирать выдачу друг друга.
14 ноя 2017 в 7:33
@Sergey может и можно) Просто не шибко ориентируюсь в linux, поэтому и спрашиваю. Спасибо за мысль, проштудирую тему.
14 ноя 2017 в 7:39
@leaf идея с syslog предополагает заменить все echo на syslog()? совершенно верно. Можно даже поднапрячься и написать макрос 🙂 просматривать в «live-режиме»? Тем же tail? — разумеется. Лично я, при отладке, делаю так: tail -f /var/log/messages | grep svl & Внимание: svl — это идентификатор, который я указал в openlog(). Амперсенд в конце командной строки уводит эту команду в фон и я могу дальше работать в терминале любым образом. А интересующие меня сообщения будут выведены на терминал, только когда они появляются реально.
Проверка работы cron в Unix/Linux
Cron — это демон, который запускает задачи по указанному (заданному) времени и который работает в наиболее распространенных дистрибутивах Unix / Linux. Поскольку cronjobs основаны на времени, иногда необходимо проверить и убедиться, что задание выполнялось в запланированное время. Иногда люди настраивают cron чтобы они отправляли вывод скрипта через системную почту или перенаправляюте вывод в файл; однако не все кроны настроены одинаково, и мние из них, могут быть настроены на отправку вывода в /dev/null, и тем самым, препятствуя любой возможности проверить выполняемое задание.
Первое что стоит проверить — это наличие ПИДа по крону:
# pgrep crond
# ps ax | grep crond | grep -Ev grep
crond, если он не настроен иначе, будет отправлять сообщение журнала в syslog каждый раз, когда он вызывает запланированное задание. Самый простой способ проверить работу cron на попытку срабатываания задание, — это проверить лог-файл.
В зависимости от Unix/Linux ОС, данный файл может иметь другое название.
Если у вас, CentOS/Fedora/RedHat, то просмотреть нужно:
# less /var/log/cron
Можно отсеять ненужное и поискать только необходимую крон-джобу, например:
# cat /var/log/cron| grep -E "back" Nov 28 00:00:01 linux-notes CROND[212211]: (root) CMD (/usr/bin/bash /home/linux/scripts/backUPs.sh) Dec 1 00:00:01 linux-notes CROND[126039]: (root) CMD (/usr/bin/bash /home/linux/scripts/backUPs.sh)
Собственно, все наглядно видно.
Если у вас, Ubuntu/Debian, то просмотреть нужно:
# less /var/log/syslog
Иногда, системные администраторы меняют вывод крона и для того, чтобы проверить куда пишуться логи по cron-job-ам, выполните:
# grep cron /etc/rsyslog.conf *.info;mail.none;authpriv.none;cron.none /var/log/messages # Log cron stuff cron.* /var/log/cron
С вывода видно, что у меня используется стандартный файл.
Так же, стоит проверить как настраивали крон-джобы:
# crontab -l
# crontab -l -u some_another_user
Возможно было перенаправление вывода в какой-то файл для дальнейшего анализа.
Стоит отметить, то — что некоторые кроны лежат тут:
# ls -lah /etc/cron.daily/ # ls -lah /etc/cron.hourly/ # ls -lah /etc/cron.weekly/ # ls -lah /etc/cron.monthly/
Бывает некоторые задачи запихивают туда.
Чтобы запретить или разрешить добавление крон-задат, нужно прописать юзера в:
# vim /etc/cron.d/cron.allow # vim /etc/cron.d/cron.deny
Так же, можно восспользоватся следующими командами для проверки статуса, запуска/остановки/перезапуска службы:
# service cron status # service cron start # service cron stop # service cron restart
Это все действия были для Linux, но сейчас приведу пример и для mac os x.
Недавно мне пришлось отлаживать работу Cron и проверять, действительно ли она выполняется по заданному расписанию. Я начал искать и проверять все логи и… нашел вроде бы подходящий файл для этого:
# grep cron /var/log/system.log
Но в нем не было признаков логирования крона!
Включить logging для Cron в Mac OSX
# vim /etc/syslog.conf
cron.* /var/log/cron.log
Для перезапуска syslog-а, выполняем:
# launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist # launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist
Проверяем что получилось!
А для помощи, можно вызвать:
# man crontab
А на этом, у меня все, статья «Проверка работы cron в Unix/Linux» завершена.
This entry was posted in Debian’s, FreeBSD, Kali Linux, MacOS, RHEL’s. Bookmark the permalink.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Рубрики
- Arch Linux (167)
- Commands (36)
- Debian’s (635)
- Administration tools Ubuntu (37)
- Backups Debian’s (7)
- Database в Ubuntu (58)
- Games (игры) (1)
- Monitoring в Debian и Ubuntu (49)
- Virtualization в Ubuntu / Debian/ Linux Mint (41)
- Docker (22)
- Kubernetes (6)
- KVM (4)
- OpenVZ (3)
- Vagrant (5)
- VirtualBox (6)
- ArgoCD (1)
- Concourse (1)
- Gitlab (1)
- Jenkinks (4)
- Spinnaker (1)
- Apache (32)
- Cherokee (1)
- FTP-services (5)
- Lighttpd (1)
- Nginx (26)
- PHP (27)
- Proxy для Debian’s (2)
- Tomcat (4)
- Панели управления в Ubuntu/Debian/Mint (24)
- Установка и настройка почты на Ubuntu/Debian (12)
- Хранилища (clouds) (2)
- Administration tools freeBSD (19)
- Database во FreeBSD (52)
- Monitoring во freeBSD (37)
- Virtualization во FreeBSD (22)
- VoIP (1)
- Установка Web сервисов (91)
- Установка и настройка почты (6)
- Установка из ports (пакетов) (19)
- Установка из sorce code (исходников) (23)
- Непрерывная интеграция (CI) (27)
- Database в MacOS (36)
- Monitoring в Mac OS (31)
- Security (безопасность) (12)
- Virtualization в Mac OS (30)
- Docker (19)
- Kubernetes (6)
- Vagrant (5)
- VirtualBox (5)
- ArgoCD (1)
- CircleCI (1)
- Concourse (1)
- Gitlab (1)
- Jenkinks (4)
- Spinnaker (1)
- Administration tools CentOS (49)
- Backups RPM’s (4)
- Database в CentOS (68)
- Monitoring в CentOS (67)
- Virtualization в CentOS/ Red Hat/ Fedora (42)
- Docker (23)
- Kubernetes (6)
- KVM (5)
- OpenVZ (2)
- Vagrant (5)
- VirtualBox (6)
- VMWare (3)
- ArgoCD (1)
- Concourse (1)
- Gitlab (1)
- Jenkinks (4)
- Spinnaker (1)
- Apache (35)
- Cherokee (1)
- DNS (3)
- FTP (10)
- Nginx (33)
- PHP (34)
- Proxy для RedHat’s (2)
- Tomcat (2)
- Voice (2)
- Панели управления в CentOS/Red Hat/Fedora (27)
- Прокси сервер на CentOS/RHEL/Fedora (4)
- Установка и настройка почты на CentOS/RHEL/Fedora (14)
- Хранилища (clouds) (1)
соц сети
Архив новостей
Свежие записи
- Pull/Push AWS ECR образов через AWS Route53 CNAME 17.11.2021
- openpgp: signature made by unknown entity в Terraform 09.11.2021
- Установка Terraformer в Unix/Linux 31.05.2021
- Установка ArgoCD в Unix/Linux 06.01.2021
- Установка tfswitch в Unix/Linux 08.12.2020
Свежие комментарии
- Альф к записи Утилита pv — прогресс bar для консольных утилит в Unix/Linux
- Александр к записи Оптимизация настроек Zabbix
- Вадим к записи Переключить версию python в Unix/Linux
- Максим к записи Сохраняем все резервные копии в Dropbox
- Артём к записи Переключить версию python в Unix/Linux
Сбор и анализ логов в Linux
Журналирование событий, происходящих в системе является неотъемлемой частью функционала любого серьезного программного обеспечения. Операционная система или приложение должны в обязательном порядке рассказывать о своей жизни: регистрировать входы в систему, сбои, ошибки и другие значительные события.
В этой статье мы будем говорить о том, как устроено логирование событий в ОС Linux. В качестве примера будет рассматриваться Ubuntu Linux 22.04, однако в других дистрибутивах основные элементы будут сходными.
Локальные логи
В Линуксе журналируются как системные события, так и события от приложений и служб. По умолчанию события журналируются в каталог /var/log/. В нем имеется множество различных *.log файлов содержащих события от различных источников в текстовом виде.
В зависимости от установленных в системе приложений, в каталоге /var/log могут находиться различные файлы журналов. Но мы приведем список основных файлов журналов:
Файлы /var/log/syslog или /var/log/messages — глобальный системный журнал. В нем мы можем найти события, произошедшие с момента запуска системы от различных компонентов ОС — ядра, служб, устройств и т. д.
Журнал событий var/log/kern.log — содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок, произошедших при работе пользовательских модулей встроенных в ядро.
Журналы /var/log/auth.log или /var/log/secure — наиболее интересны для безопасников, так как они содержат информацию об авторизации пользователей, то есть попытки не/успешных входов в систему и методов аутентификации.
События от оборудования и драйверов устройств находятся в файле /var/log/dmesg. В этом файле фиксируются ошибки работы драйверов и оборудования.
События установки системы можно найти в файле /var/log/anaconda.log, а в файле /var/log/boot.log находятся логи загрузки системы.
Еще один журнал событий, который представляет особый интерес для специалистов по информационной безопасности это /var/log/audit — лог демона auditd. Логирование аудита мы еще рассмотрим далее в этой статье.
Журнал демона crond /var/log/cron — содержит результаты выполнения различных событий планировщика задач cron.
Это основные журналы событий, которые есть в большинстве дистрибутивов Linux. Также в зависимости от установленных приложений в /var/log/ могут находиться логи БД MySQL или веб серверов Apache/Nginx.
Что, собственно, пишем
Каждое приложение само решает, какие события ему писать в лог, поэтому общим у всех событий в /var/log будет разве что формат, да и то с некоторыми исключениями. Поэтому, в качестве примера содержимого журнала событий рассмотрим сообщения в /var/log/messages.
Уровни логов или приоритеты определяет ядро Linux. В зависимости от важности события, ему присваивается один из приоритетов, представленных ниже:
- KERN_EMERG — система неработоспособна;
- KERN_ALERT — нужно немедленно принять меры;
- KERN_CRIT — критическая ошибка;
- KERN_ERR — обычная ошибка;
- KERN_WARNING — предупреждение;
- KERN_NOTICE — замечание;
- KERN_INFO — информационное сообщение;
- KERN_DEBUG — сообщения отладки.
Соответственно, при логировании можно указать в настройках работы Syslog, события с каким приоритетом сохранять в каком файле.
Еще одним важным значением в сообщения является категория (Facility). Категории могут принимать значения от 0 до 23, им соответствуют различные категории системных служб: 0.
— kernel, 2 — mail, 7 — news и т. д. Последние 8 категорий — от local0 до local7 — определены для служб, не попадающих в предопределённые категории.
Локальные недостатки
По умолчанию все журналы событий хранятся на машине локально. Однако даже в небольшой сети такой способ хранения логов не является оптимальным. Для чего нужны журналы событий? Для решения возможных проблем с производительностью, для мониторинга состояния системы и для своевременного выявления подозрительных и вредоносных активностей. И для всех этих активностей лучше использовать централизованное хранение логов на отдельном сервере или хранилище. Дело в том, что на локальных узлах в целях экономии места логи циклически удаляются (ротируются) то есть, при достижении максимального объема файла журнала, самые старые события удаляются. В результате мы можем лишиться важных событий просто потому что они уже затерлись более новыми. Также, не слишком удобно проверять логи локально на каждом узле, централизованно анализировать гораздо проще. Большой поток событий может создавать дополнительную нагрузку на дисковую подсистему.
Отдельная история про безопасность. В случае, если злоумышленник проник в систему и захватил права root он сможет без труда изменить файлы журналов так, чтобы скрыть следы своих действий. В процессе взлома такие события, как подбор пароля и вход в систему обязательно отражаются в логах, и если их сразу передать на центральный сервер и проанализировать, то можно предотвратить атаку еще до того, как злоумышленнику удалось захватить систему.
Таким образом, необходимо сохранять основные события со всех узлов на отдельном сервере. Изначально в ОС Linux для этого использовался протокол Syslog, по которому события могли передаваться между серверами. Но этот протокол имеет существенные недостатки. В качестве транспортного протокола Syslog использует UDP, то есть отправка пакетов ведется без подтверждения получения. Таким образом нет никакой гарантии, что отправленное с одного узла событие на сервер Syslog будет доставлено. В случае с критически важными событиями это не очень хорошо.
Кроме того, протокол Syslog не предусматривает никаких механизмов защиты. События передаются в открытом виде и могут быть легко перехвачены.
Rsyslog
В качестве альтернативы можно использовать протокол RSyslog (Rocket‑fast System for log processing). Преимуществами этого протокола является наличие многопоточности (то есть возможность обрабатывать большой объем событий), использование протокола TCP на транспортном уровне, наличие шифрования SSL, а также возможность сохранения готовых событий в базы данных (MySQL, PostgreSQL, Oracle). Отдельного внимания заслуживает возможность фильтрации по любой части лога и полностью настраиваемый формат вывода событий.
Ниже приводится фрагмент конфига /etc/rsyslog.conf с клиентской машины.
В качестве примера настроим пересылку логов с клиента на сервер. Для этого на стороне сервера необходимо в файле /etc/rsyslog.conf добавить следующие строки:
Для большей надежности мы используем TCP в качестве транспортного протокола и стандартный порт 514, на котором сервер будет слушать трафик.
Для того, чтобы не запутаться в собираемых журналах событий лучше всего сразу сохранять пришедши е события в отдельных файлах. Идея складывать все события в один файл очень плоха, так как файлы логов должны, либо подвергаться циклической чистке, когда старые события удаляются, либо архивироваться. И то, и другое ведет к тому, что вы можете потерять часть важных событий. Поэтому лучше использовать следующую структуру /var/log/rsyslog/ИМЯ_УЗЛА_источника/приложение_источник.log . Для этого надо добавить в файл конфигураций следующие строки:
Так как Rsyslog может содержать набор правил для обработки приходящих событий, нам необходимо явно сообщить ему, что пришедшие события не надо дополнительно обрабатывать.
Для этого добавим:
Далее перезапускаем службу Rsyslog:
systemctl restart rsyslog
На клиенте необходимо настроить пересылку событий на сервер. Для этого нужно создать отдельный файл конфигураций:
В этот файл добавляем строку, указывающую какие журналы, и куда необходимо пересылать
В примере мы пересылаем все события с клиента на порт 514 сервера 192.168.222.135.
Но если нас не интересуют все события, а нужны только логи из конкретной категории, например аутентификации, то нужно указать следующее:
Далее также перезапускаем Rsyslog
systemctl restart rsyslog
В журнале событий на сервере можно убедиться, что события с клиента успешно приходят:
Модули Rsyslog
Иногда возникает необходимость в более интеллектуальной обработке журналов событий, поступающих с источников. Для этого в Rsyslog имеются модули. Модули ввода — начинаются с im, собирают информацию из различных источников. Модули вывода — начинаются на om, и они отправляют сообщения. Могут отправлять сообщения как в файл так и по сети или складывать в базу. Модули фильтрации — начинаются с fm. Фильтруют сообщения по разным параметрам. Модули парсинга — начинаются с pm. Позволяют проводить синтаксический анализ. Модули модификации сообщений — начинаются с mm. Меняют содержимое обрабатываемых сообщений. Модули генерации строк — начинаются с sm. Позволяют генерировать строки на основе обрабатываемых сообщений.
Посмотрим пример для того, чтобы было понятно, о чем идет речь. В следующем примере мы будем на клиенте отслеживать изменения в файле audit.log и отправлять на сервер события с уровнем warning и выше и категорией local0.
На сервере также необходимо модифицировать файл конфигураций для того, чтобы данные события сохранялись в отдельном файле:
$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
Сохранение в БД
Собранные события удобно хранить в текстовых файлах лишь когда их не более десятка. При большем объем лучше использовать СУБД для централизованного хранения и обработки событий. В качестве примера будем отправлять все события в MySQL. Вот общий формат таких настроек:
В случае использования PostgreSQL формат будет следующий:
Использование СУБД позволяет не только собирать и хранить события, но и делать запросы по наличию тех или иных событий, строить отчеты и реагировать на появление определенных событий. Хотя, когда количество источников начинает измеряться сотнями, для работы с событиями уже лучше использовать специализированные решения. Например, для обработки событий ИБ лучше использовать решения класса SIEM (Security Information Event Management).
Заключение
В этой статье были рассмотрены основы журналирования в ОС Linux. Помимо описанных Syslog и Rsyslog, в Линуксе существуют также другие механизмы журналирования, да и Rsyslog содержит массу полезных функций. Так что продолжение следует…
Что такое инфраструктура как код? Что значит «сервера снежинки»? Как автоматизировать работу с серверами? Ответы на эти и другие вопросы дадим на бесплатном уроке, после которого вы узнаете как автоматизировать рутинные процессы создания и настройки серверов с помощью инструментов vagrant, terraform, ansible.
- Блог компании OTUS
- Настройка Linux
- *nix
Как найти и читать логи в Linux
Что такое логи Linux? Все системы Linux создают и хранят файлы логов информации для процессов загрузки, приложений и других событий. Эти файлы могут быть полезным ресурсом для устранения неполадок системы.
Большинство файлов логов Linux хранятся в простом текстовом файле ASCII и находятся в каталоге и подкаталоге /var/log . Логи создаются системным демоном логов Linux, syslogd или rsyslogd .
В этом руководстве вы узнаете, как находить и читать файлы логов Linux, а также настраивать демон ведения системных логов.
Как просматривать логи Linux
1. Сначала откройте терминал Linux как пользователь root. Это позволит получить root-права.
2. Используйте следующую команду для просмотра папки где находятся файлов логов:
cd /var/log
3. Чтобы просмотреть логи, введите следующую команду:
Команда отображает все файлы логов Linux, такие как kern.log и boot.log . Эти файлы содержат необходимую информацию для правильного функционирования операционной системы.
Доступ к файлам логов осуществляется с использованием привилегий root. По определению, root — это учетная запись по умолчанию, которая имеет доступ ко всем файлам Linux.
Используйте следующий пример строковой команды для доступа к соответствующему файлу:
sudo less [log name here].log
Эта команда отображает временную шкалу всей информации, относящейся к этой операции.
Обратите внимание, что файлы логов хранятся в виде обычного текста, поэтому их можно просматривать с помощью следующих стандартных команд:
- zcat — Отображает все содержимое logfile.gz
- zmore — Просмотр файла по страницам, не распаковывая файлы
- zgrep — Поиск внутри сжатого файла
- grep — Найти все вхождения поискового запроса в файле или отфильтровать файл логов
- tail — Выводит последние несколько строк файлов
- head — Просмотр самого начала текстовых файлов
- vim — Просмотр при помощи текстового редактора vim
- nano — Просмотр при помощи текстового редактора nano
Важные системные логи Linux
Логи могут многое рассказать о работе системы. Хорошее понимание каждого типа файла поможет различать соответствующие логи.
Большинство каталогов можно сгруппировать в одну из четырех категорий:
- Системные логи (System Logs)
- Логи событий (Event Logs)
- Логи приложений (Application Logs)
- Логи обслуживания (Service Logs)
Многие из этих логов могут быть расположены в подкаталоге var/log .
Системные логи
Файлы логов необходимы для работы Linux. Они содержат значительный объем информации о функциональности системы. Наиболее распространенные файлы логов:
- /var/log/syslog : глобальный системный журнал (может быть в /var/log/messages )
- /var/log/boot.log : лог загрузки системы, где хранится вся информация, относящаяся к операциям загрузки
- /var/log/auth.log : логи аутентификации, который хранит все логи аутентификации, включая успешные и неудачные попытки (может быть в /var/log/secure )
- /var/log/httpd/ : логи доступа и ошибок Apache
- /var/log/mysqld.log : файл логов сервера базы данных MySQL
- /var/log/debug : логи отладки, который хранит подробные сообщения, связанные с отладкой, и полезен для устранения неполадок определенных системных операций
- /var/log/daemon.log : логи демона, который содержит информацию о событиях, связанных с запуском операции Linux
- /var/log/maillog : логи почтового сервера, где хранится информация, относящаяся к почтовым серверам и архивированию писем
- /var/log/kern.log : логи ядра, где хранится информация из ядра Linux
- /var/log/yum.log : логи команд Yum
- /var/log/dmesg : логи драйверов
- /var/log/boot.log : логи загрузки
- /var/log/cron : логи службы crond
Демон системных логов
Логирование осуществляется при помощи демона syslogd
Программы отправляют свои записи журнала в syslogd, который обращается к конфигурационному файлу /etc/syslogd.conf или /etc/syslog и при обнаружении совпадения записывает сообщение журнала в нужный файл журнала. Каждый файл состоит из селектора и поля ввода действия. Демон syslogd также может пересылать сообщения журнала. Это может быть полезно для отладки. Этот файл выглядит приерно так:
Dec 19 15:12:42 backup.main.merionet.ru sbatchd[495]: sbatchd/main: ls_info() failed: LIM is down; try later; trying . Dec 19 15:14:28 system.main.merionet.ru pop-proxy[27283]: Connection from 186.115.198.84 Dec 19 15:14:30 control.main.merionet.ru pingem[271] : office.main.merionet.ru has not answered 42 times Dec 19 15:15:05 service.main.merionet.ru vmunix: Multiple softerrors: Seen 100Corrected Softerrors from SIMM J0201 Dec 19 15:15:16 backup.main.merionet.ru PAM_unix[17405]: (sshd) session closed 'for user trent
Логи приложений
Логи приложений хранят информацию, относящуюся к любому запускаемому приложению. Это может включать сообщения об ошибках, признаки взлома системы и строку идентификации браузера.
Файлы логов, которые попадают в эту категорию, включают логи системы печати CUPS, лог Rootkit Hunter, логи HTTP-сервера Apache, логи SMB-сервера Samba и лог сервера X11.
Логи не в удобочитаемом формате
Не все логи созданы в удобочитаемом формате. Некоторые предназначены только для чтения системными приложениями. Такие файлы часто связаны с информацией для входа. Они включают логи сбоев входа в систему, логи последних входов в систему и записи входа в систему.
Существуют инструменты и программное обеспечение для чтения файлов логов Linux. Они не нужны для чтения файлов, так как большинство из них можно прочитать непосредственно с терминала Linux.
Графические интерфейсы для просмотра файлов логов Linux
System Log Viewer — это графический интерфейс, который можно использовать для отслеживания системных логов.
Интерфейс предоставляет несколько функций для управления логами, включая отображение статистики лога. Это удобный графический интерфейс для мониторинга логов.
В качестве альтернативы можно использовать Xlogmaster, который может отслеживать значительное количество файлов логов.
Xlogmaster полезен для повышения безопасности. Он переводит все данные для выделения и скрытия строк и отображает эту информацию для выполнения действий, запрошенных пользователем.
Как настроить файлы логов в Ubuntu и CentOS
Начнем с примера CentOS. Чтобы просмотреть пользователей, которые в настоящее время вошли на сервер Linux, введите команду who от имени пользователя root:
Здесь также отображается история входа в систему пользователей. Для просмотра истории входа системного администратора введите следующую команду:
last reboot
Чтобы просмотреть информацию о последнем входе в систему, введите:
lastlog
Выполнить ротацию лога
Файлы логов, в конце которых добавлены нули, являются повернутыми файлами. Это означает, что имена файлов логов были автоматически изменены в системе.
Целью ротации логов является сжатие устаревших логов, занимающих место. Ротацию лога можно выполнить с помощью команды logrotate . Эта команда вращает, сжимает и отправляет системные логи по почте.
logrotate обрабатывает системы, которые создают значительные объемы файлов логов. Эта команда используется планировщиком cron и считывает файл конфигурации logrotate /etc/logrotate.conf . Он также используется для чтения файлов в каталоге конфигурации logrotate.
Чтобы включить дополнительные функции для logrotate, начните с ввода следующей команды:
var/log/log name here].log
Он сжимает и изменяет размер желаемого файла логов.
Команды выполняют следующие действия:
- missingok — сообщает logrotate не выводить ошибку, если файл логов отсутствует.
- notifempty — не выполняет ротацию файла логов, если он пуст. Уменьшает размер файла лога с помощью gzip
- size — гарантирует, что файл логов не превышает указанный размер, и поворачивает его в противном случае
- daily — меняет файлы журналов по ежедневному расписанию. Это также можно делать по недельному или ежемесячному расписанию.
- create — создает файл логов, в котором владелец и группа являются пользователем root
Итоги
Тщательное понимание того, как просматривать и читать логи Linux, необходимо для устранения неполадок в системе Linux. Использование правильных команд и инструментов может упростить этот процесс.