Ubuntu журнал ошибок

sudo dmesg У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске. sudo dmesg | grep sda Вы увидите лог загрузки системы ubuntu...

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

Традиционно логи в Linux хранятся в директории /var/log. Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.

  1. syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
  2. auth.log — лог авторизации и аутентификации в системе.
  3. dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
  4. alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
  5. kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
  6. maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
  7. dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
  8. lastlog и wtmp — информация о прошлых авторизациях пользователей.

Лог загрузки

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

sudo dmesg

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

sudo dmesg | grep sda

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

sudo dmesg | grep error

И так далее.  Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg.

Логи авторизации, в том числе ssh

Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log. Авторизация по ssh там будет выглядеть следующим образом.

sshd[2774]: Accepted publickey for root from 21.17.214.129 port 2673 ssh2: RSA SHA256:MCDja9Ve7rYZCzeVGpYXpqRxfAanWwVkcd+lU3GS
sshd[2774]: pam_unix(sshd:session): session opened for user root by (uid=0)
systemd-logind[628]: New session 6 of user root.

Здесь мы видим ip адрес, с которого произошло подключение и слепок сертификата, так как аутентификация была произведена с его помощью. Если хотите повысить уровень логирования подключений по ssh и получать больше информации, то можете отредактировать конфигурационный файл sshd — /etc/ssh/sshd_config, добавив туда следующий параметр.

LogLevel VERBOSE

Не забудьте перезапустить службу sshd для принятия изменений:

sudo systemctl restart sshd

После этого логирование подключений по ssh будет более подробное.

Лог локального входа в ubuntu тоже хранится в файле auth.log. Информация о подключении через консоль выглядит следующим образом.

login[680]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
systemd-logind[628]: New session 9 of user root.
login[3094]: ROOT LOGIN on '/dev/tty1'

Устройство /dev/tty1 говорит о том, что вход локальный.

Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog.

Примерно то же самое можно увидеть с помощью utmpdump.

sudo utmpdump /var/log/wtmp

Логи ошибок в Ubuntu

Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:

  • error или err
  • critical или crit
  • debug
  • warn

Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (warn).

sudo dmesg -l warn

А теперь проверим ошибки в системном логе.

sudo cat /var/log/syslog | grep error

Видим некоторые ошибки в службе systemd-resolved.

Cron logs

Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.

Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.

cron.*				/var/log/cron.log

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

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

Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.

sudo systemctl restart rsyslog
sudo systemctl restart cron

Проверяем cron.log

sudo cat /var/log/cron.log

Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.

Лог действий пользователя

Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.

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

Defaults logfile=/var/log/sudo.log

Теперь выполните какую-нибудь команду через sudo.

sudo cat /var/log/cron.log

Проверяем sudo.log.

Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ;
    COMMAND=/usr/bin/cat /var/log/cron.log

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

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

Системные администраторы, да и обычные пользователи 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 License

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

Об авторе

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

Tag/tag.png

Needs Expansion
This article is incomplete, and needs to be expanded. More info…

Contents

  1. Introduction
  2. Target Audience
  3. System Logs

    1. Authorization Log
    2. Daemon Log
    3. Debug Log
    4. Kernel Log
    5. Kernel Ring Buffer
    6. System Log
  4. Application Logs

    1. Apache HTTP Server Logs
    2. CUPS Print System Logs
    3. Rootkit Hunter Log
    4. Samba SMB Server Logs
    5. X11 Server Log
  5. Non-Human-Readable Logs

    1. Login Failures Log
    2. Last Logins Log
    3. Login Records Log
  6. System Logging Daemon (syslogd)

    1. Configuration of syslogd
    2. Echoing Messages to syslogd With Logger
    3. Log Rotation
  7. Essential Commands

    1. Getting Started
    2. Editing Files
    3. Viewing Files
    4. Viewing the Beginning of Files
    5. Viewing the End of Files
    6. Watching a Changing File
    7. Searching Files
  8. Resources

    1. Local System Resources
    2. WWW Resources

Introduction

One of the things which makes GNU/Linux a great operating system is that virtually anything and everything happening on and to the system may be logged in some manner. This information is invaluable for using the system in an informed manner, and should be one of the first resources you use to trouble-shoot system and application issues. The logs can tell you almost anything you need to know, as long as you have an idea where to look first.

Your Ubuntu system provides vital information using various system log files. These log files are typically plain ASCII text in a standard log file format, and most of them sit in the traditional system log subdirectory /var/log. Many are generated by the system log daemon, syslogd on behalf of the system and certain applications, while some applications generate their own logs by writing directly to files in /var/log.

This guide talks about how to read and use several of these system log files, how to use and configure the system logging daemon, syslogd, and how log rotation works. See the Resources section for additional information.

Target Audience

This guide will be simple enough to use if you have any experience using the console and editing text files using a text editor. See the end of this document for some essential commands that may help you find your way around these files if you’re relatively new to the command line.

System Logs

System logs deal primarily with the functioning of the Ubuntu system, not necessarily with additional applications added by users. Examples include authorization mechanisms, system daemons, system messages, and the all-encompassing system log itself, syslog.

The Authorization Log tracks usage of authorization systems, the mechanisms for authorizing users which prompt for user passwords, such as the Pluggable Authentication Module (PAM) system, the sudo command, remote logins to sshd and so on. The Authorization Log file may be accessed at /var/log/auth.log. This log is useful for learning about user logins and usage of the sudo command.

Use grep to cut down on the volume. For example, to see only information in the Authorization Log pertaining to sshd logins, use this:

grep sshd /var/log/auth.log | less

Daemon Log

A daemon is a program that runs in the background, generally without human intervention, performing some operation important to the proper running of your system. The daemon log at /var/log/daemon.log and contains information about running system and application daemons such as the Gnome Display Manager daemon gdm, the Bluetooth HCI daemon hcid, or the MySQL database daemon mysqld. This can help you trouble-shoot problems with a particular daemon.

Again, use grep to find specific information, plugging in the name of the daemon you’re interested in.

Debug Log

The debug log at /var/log/debug and provides detailed debug messages from the Ubuntu system and applications which log to syslogd at the DEBUG level.

Kernel Log

The kernel log at /var/log/kern.log provides a detailed log of messages from the Ubuntu Linux kernel. These messages may prove useful for trouble-shooting a new or custom-built kernel, for example.

Kernel Ring Buffer

The kernel ring buffer is not really a log file per se, but rather an area in the running kernel you can query for kernel bootup messages via the dmesg utility. To see the messages, use this:

dmesg | less

Or to search for lines that mention the Plug & Play system, for example, use grep like this:

dmesg | grep pnp | less

By default, the system initialization script /etc/init.d/bootmisc.sh sends all bootup messages to the file /var/log/dmesg as well. You can view and search this file the usual way.

System Log

The system log typically contains the greatest deal of information by default about your Ubuntu system. It is located at /var/log/syslog, and may contain information other logs do not. Consult the System Log when you can’t locate the desired log information in another log. It also contains everything that used to be in /var/log/messages.

Application Logs

Many applications also create logs in /var/log. If you list the contents of your /var/log subdirectory, you will see familiar names, such as /var/log/apache2 representing the logs for the Apache 2 web server, or /var/log/samba, which contains the logs for the Samba server. This section of the guide introduces some specific examples of application logs, and information contained within them.

Apache HTTP Server Logs

The default installation for Apache2 on Ubuntu creates a log subdirectory: /var/log/apache2. Within this subdirectory are two log files with two distinct purposes:

  • /var/log/apache2/access.log — records of every page served and every file loaded by the web server.

  • /var/log/apache2/error.log — records of all error conditions reported by the HTTP server

By default, every time Apache accesses a file or page, the access logs record the IP address, time and date, browser identification string, HTTP result code and the text of the actual query, which will generally be a GET for a page view. Look at the Apache documentation for a complete rundown; quite a lot can be gleaned from this file, and indeed many statistical packages exist that perform analyses of these logs.

Also, every time any error occurs, Apache adds a line to the error log. If you run PHP with error and warning messages disabled, this can be your only way to identify bugs.

CUPS Print System Logs

The Common Unix Printing System (CUPS) uses the default log file /var/log/cups/error_log to store informational and error messages. If you need to solve a printing issue in Ubuntu, this log may be a good place to start.

Rootkit Hunter Log

The Rootkit Hunter utility (rkhunter) checks your Ubuntu system for backdoors, sniffers and rootkits, which are all signs of compromise of your system. The log rkhunter uses is located at /var/log/rkhunter.log.

Samba SMB Server Logs

The Server Message Block Protocol (SMB) server, Samba is popularly used for sharing files between your Ubuntu computer and other computers which support the SMB protocol. Samba keeps three distinct types of logs in the subdirectory /var/log/samba:

  • log.nmbd — messages related to Samba’s NETBIOS over IP functionality (the network stuff)

  • log.smbd — messages related to Samba’s SMB/CIFS functionality (the file and print sharing stuff)

  • log.[IP_ADDRESS] — messages related to requests for services from the IP address contained in the log file name, for example, log.192.168.1.1.

X11 Server Log

The default X11 Windowing Server in use with Ubuntu is the Xorg X11 server, and assuming your computer has only one display defined, it stores log messages in the file /var/log/Xorg.0.log. This log is helpful for diagnosing issues with your X11 environment.

Non-Human-Readable Logs

Some log files found in the /var/log subdirectory are designed to be readable by applications, not necessarily by humans. Some examples of such log files which appear in /var/log follow.

Login Failures Log

The login failures log located at /var/log/faillog is actually designed to be parsed and displayed by the faillog command. For example, to print recent login failures, use this:

faillog

Last Logins Log

The last logins log at /var/log/lastlog should not typically be parsed and examined by humans, but rather should be used in conjunction with the lastlog command. For example to see a listing of logins with the lastlog command, displayed one page per screen with the less command, use the following command:

lastlog | less

Login Records Log

The file /var/log/wtmp contains login records, but unlike /var/log/lastlog above, /var/log/wtmp is not used to show a list of recent logins, but is instead used by other utilities such as the who command to present a listed of currently logged in users. This command will show the users currently logged in to your machine:

who

System Logging Daemon (syslogd)

The system logging daemon syslogd, also known as sysklogd, awaits logging messages from numerous sources and routes the messages to the appropriate file or network destination. Messages logged to syslogd usually contain common elements like system hostnames and time-stamps in addition to the specific log information.

Configuration of syslogd

The syslogd daemon’s configuration file is /etc/syslog.conf. Each entry in this file consists of two fields, the selector and the action. The selector field specifies a facility to be logged, such as for example the auth facility which deals with authorization, and a priority level to log such information at, such as info, or warning. The action field consists of a target for the log information, such as a standard log file (i.e. /var/log/syslog), or the hostname of a remote computer to send the log information to.

Echoing Messages to syslogd With Logger

A neat utility exists in the logger tool, which allows one to place messages into the System Log (i.e. /var/log/syslog) arbitrarily. For example, assume your user name is buddha, and you would like to enter a message into the syslog about a particularly delicious pizza you’re eating, you could use a command such as the following at a terminal prompt:

logger This Pizza from Vinnys Gourmet Rocks

and you would end up with a line in the /var/log/syslog file like this:

Jan 12 23:34:45 localhost buddha: This Pizza from Vinnys Gourmet Rocks

You can even specify a tag the messages come from, and redirect the output standard error too.

#
# sample logger error jive
#
logmsg="/usr/bin/logger -s -t MyScript "

# announce what this script is, even to the log
$logmsg "Directory Checker FooScript Jive 1.0"

# test for the existence of Fred's home dir on this machine
if [ -d /home/fred ]; then
   $logmsg "I. Fred's Home Directory Found"
else
   $logmsg "E. Fred's Home Directory was NOT Found. Boo Hoo."
   exit 1
fi

Executing this script as chkdir.sh on the machine butters where Fred does not have a home directory, /home/fred, gives the following results:

bumpy@butters:~$./chkdir.sh
MyScript: Directory Checker FooScript Jive 1.0
MyScript: E. Fred's Home Directory was NOT Found. Boo Hoo.
bumpy@butters:~$tail -n 2 /var/log/syslog
Jan 12 23:23:11 localhost MyScript: Directory Checker FooScript Jive 1.0
Jan 12 23:23:11 localhost MyScript: E. Fred's Home Directory was NOT Found. Boo Hoo.

So, as you can see, we received the messages both via standard error, at the terminal prompt, and they also appear in our syslog.

Log Rotation

When viewing directory listings in /var/log or any of its subdirectories, you may encounter log files with names such as daemon.log.0, daemon.log.1.gz, and so on. What are these log files? They are ‘rotated’ log files. That is, they have automatically been renamed after a predefined time-frame, and a new original log started. After even more time the log files are compressed with the gzip utility as in the case of the example daemon.log.1.gz. The purpose of log rotation is to archive and compress old logs so that they consume less disk space, but are still available for inspection as needed. What handles this functionality? Why, the logrotate command of course! Typically, logrotate is called from the system-wide cron script /etc/cron.daily/logrotate, and further defined by the configuration file /etc/logrotate.conf. Individual configuration files can be added into /etc/logrotate.d (where the apache2 and mysql configurations are stored for example).

This guide will not cover the myriad of ways logrotate may be configured to handle the automatic rotation of any log file on your Ubuntu system. For more detail, check the Resources section of this guide.

IconsPage/note.png NOTE: You may also rotate system log files via the cron.daily script /etc/cron.daily/sysklogd instead of using logrotate. Actually, the utility savelog may produce unexpected results on log rotation which configuring logrotate seems to have no effect on. In those cases, you should check the cron.daily sysklogd script in /etc/cron.daily/sysklogd and read the savelog manual page to see if savelog is not in fact doing the rotation in a way that is not what you are specifying with logrotate.

Essential Commands

If you’re new to the console and the Linux command line, these commands will get you up and running to the point where you can work with log files at a basic level.

Getting Started

To change to the log directory, where most of these files sit, use the cd command. This saves having to type out a full path name for every subsequent command:

cd /var/log

Editing Files

You can view and edit files in GEdit or Kate, the simple text editors that come with Ubuntu and Kubuntu respectively, but these can be overkill when all you want to do is look at a file or make simple changes. The easiest editor to use from the console is nano, which is less powerful but also less complicated than vim or emacs. The command to edit a particular logfile /var/log/example.log using nano is:

nano example.log

Press Ctrl+X to exit. It will ask if you want to save your changes when you exit, but unless you run it with the sudo command the files won’t be writable. In general, you won’t want to save your changes to log files, of course.

Viewing Files

To simply look at a file, an editor is overkill. Use the less command, which pages through a file one screen at a time:

less example.log

You don’t need sudo to look at a file. Press h for help, or q to quit. The cursor keys and page up/down keys will work as expected, and the slash key («/») will do a case-sensitive search; the n key repeats the last search.

Viewing the Beginning of Files

To see the first ten lines of a file, use the head command:

head example.log

To see some other number of lines from the beginning of the file, add the -n switch, thus:

head -n 20 example.log

Viewing the End of Files

To see the final ten lines of a file, the analogous command is tail:

tail example.log

Again, the -n switch gives you control over how many lines it displays:

tail -n 20 example.log

Watching a Changing File

Also, the -f («follow») switch puts tail into a loop, constantly waiting for new additions to the file it’s displaying. This is useful for monitoring files that are being updated in real time:

tail -f example.log

Press Ctrl+C to quit the loop.

Searching Files

Because log files can be large and unwieldy, it helps to be able to focus. The grep command helps you strip out only the content you care about. To find all the lines in a file containing the word «system», for example, use this:

grep "system" example.log

To find all the lines containing «system» at the beginning of the line, use this:

grep "^system" example.log

Note the caret symbol, a regular expression that matches only the start of a line. This is less useful for standard log files, which always start with a date and time, but it can be handy otherwise. Not all files have a standard format.

Any time the result of a grep is still too long, you can pipe it through less:

grep "system" example.log | less

Resources

Additional information on system and application logs and syslogd is available via the following resources:

Local System Resources

man dmesg

System manual page for the dmesg kernel ring buffer utility

man faillog

System manual page for the faillog command (and also the faillog configuration file via man 5 faillog)

man grep

System manual page for the grep pattern searching utility

man head

System manual page for the head utility

man klogd

System manual page for the kernel log daemon (klogd)

man last

System manual for the last command which shows last logged in users

man less

System manual page for the less paging utility

man logger

System manual page for the logger command-line interface to syslog utility

man logrotate

System manual page for the the logrotate utility

man savelog

System manual page for the savelog log file saving utility

man syslogd

System manual page for the system log daemon (syslogd)

man syslog.conf

System manual page for the syslogd configuration file

man tail

System manual page for the tail utility

WWW Resources

Checking Your System Logs with awk

Syslog — Watching Your Logs

http://www.ibm.com/developerworks/linux/library/l-roadmap5/-Linux Logging

Sawing Linux Logs With Simple Tools


CategorySystem

ЧТЕНИЕ И НАСТРОЙКА ЛОГОВ LINUX В UBUNTU И CENTOS

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

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

Данное руководство рассматривает различные части механизма журналирования Linux.

Примечание: Команды данного руководства были протестированы на простых установках CentOS 6.4, Ubuntu 12 и Debian 7.

Стандартные логи

По умолчанию журналы в Linux хранятся в  /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

В системе CentOS это выглядит так:

[root@TestLinux ~]# ls -l /var/log  
total 1472  
-rw-------. 1 root root   4524 Nov 15 16:04 anaconda.ifcfg.log  
-rw-------. 1 root root  59041 Nov 15 16:04 anaconda.log  
-rw-------. 1 root root  42763 Nov 15 16:04 anaconda.program.log  
-rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log  
-rw-------. 1 root root  40669 Nov 15 16:04 anaconda.syslog  
-rw-------. 1 root root  57061 Nov 15 16:04 anaconda.xlog  
-rw-------. 1 root root   1829 Nov 15 16:04 anaconda.yum.log  
drwxr-x---. 2 root root   4096 Nov 15 16:11 audit  
-rw-r--r--  1 root root   2252 Dec  9 10:27 boot.log  
-rw-------  1 root utmp    384 Dec  9 10:31 btmp  
-rw-------. 1 root utmp   1920 Nov 28 09:28 btmp-20131202  
drwxr-xr-x  2 root root   4096 Nov 29 15:47 ConsoleKit  
-rw-------  1 root root   2288 Dec  9 11:01 cron  
-rw-------. 1 root root   8809 Dec  2 17:09 cron-20131202  
-rw-r--r--  1 root root  21510 Dec  9 10:27 dmesg  
-rw-r--r--  1 root root  21351 Dec  6 16:37 dmesg.old  
-rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log  
-rw-r--r--. 1 root root 146876 Dec  9 10:44 lastlog  
-rw-------  1 root root    950 Dec  9 10:27 maillog  
-rw-------. 1 root root   4609 Dec  2 17:00 maillog-20131202  
-rw-------  1 root root 123174 Dec  9 10:27 messages  
-rw-------. 1 root root 458481 Dec  2 17:00 messages-20131202  
-rw-------  1 root root   2644 Dec  9 10:44 secure  
-rw-------. 1 root root  15984 Dec  2 17:00 secure-20131202  
-rw-------  1 root root      0 Dec  2 17:09 spooler  
-rw-------. 1 root root      0 Nov 15 16:02 spooler-20131202  
-rw-------. 1 root root      0 Nov 15 16:02 tallylog  
-rw-rw-r--. 1 root utmp  89856 Dec  9 10:44 wtmp  
-rw-------  1 root root   3778 Dec  6 16:48 yum.log

Просмотр логов

В каталоге /var/log находится несколько общих журналов:

  • wtmp
  • utmp
  • dmesg
  • messages
  • maillog или mail.log
  • spooler
  • auth.log или secure

Файлы wtmp и utmp отслеживают пользователей, вошедших и покинувших систему. Содержимое данных журналов нельзя читать с помощью простой команды «cat», для этого есть специальные команды, с которыми теперь нужно ознакомиться.

Чтобы узнать, кто в текущий момент находится на сервере Linux, нужно использовать команду «who». Она извлекает информацию из /var/run/utmp (в CentOS и Debian) или из /run/utmp (в Ubuntu).

Это пример ее работы в CentOS:

[root@TestLinux ~]# who  
root     tty1         2013-12-09 10:44  
root      pts/0        2013-12-09 10:29 (10.0.2.2)  
sysadmin pts/1        2013-12-09 10:31 (10.0.2.2)  
joeblog  pts/2        2013-12-09 10:39 (10.0.2.2)

Команда «sysadmin» выводит историю входа пользователей:

[root@TestLinux ~]# last | grep sysadmin  
sysadmin pts/1        10.0.2.2         Mon Dec  9 10:31   still logged in  
sysadmin pts/0        10.0.2.2         Fri Nov 29 15:42 - crash  (00:01)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 17:06 - 17:13  (00:06)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 16:17 - 17:05  (00:48)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 09:29 - crash  (06:04)  
sysadmin pts/0        10.0.2.2         Wed Nov 27 16:37 - down   (00:29)  
sysadmin tty1                          Wed Nov 27 14:05 - down   (00:36)  
sysadmin tty1                          Wed Nov 27 13:49 - 14:04  (00:15)

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

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

[root@TestLinux ~]# last reboot

Результат имеет примерно такой вид:

reboot   system boot  2.6.32-358.el6.x Mon Dec  9 10:27 - 10:47  (00:19)  
reboot   system boot  2.6.32-358.el6.x Fri Dec  6 16:37 - 10:47 (2+18:10)  
reboot   system boot  2.6.32-358.el6.x Fri Dec  6 16:28 - 16:36  (00:08)    reboot   system boot  2.6.32-358.el6.x Fri Dec  6 11:06 - 16:36  (05:29)  
reboot   system boot  2.6.32-358.el6.x Mon Dec  2 17:00 - 16:36 (3+23:36)  
reboot   system boot  2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34)  
reboot   system boot  2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53)  
...  
...  
wtmp begins Fri Nov 15 16:11:54 2013

Чтобы узнать время последнего входа в систему, используйте lastlog:

[root@TestLinux ~]# lastlog

Результат на CentOS выглядит примерно так:

Username        Port        From            Latest  
root            tty1                        Mon Dec  9 10:44:30 +1100 2013  
bin                                        **Never logged in**  
daemon                                     **Never logged in**  
adm                                        **Never logged in**  
lp                                         **Never logged in**  
sync                                       **Never logged in**  
shutdown                                   **Never logged in**  
halt                                       **Never logged in**  
mail                                       **Never logged in**  
uucp                                       **Never logged in**  
operator                                   **Never logged in**  
games                                      **Never logged in**  
gopher                                     **Never logged in**  
ftp                                        **Never logged in**  
nobody                                     **Never logged in**  
vcsa                                       **Never logged in**  
saslauth                                   **Never logged in**  
postfix                                    **Never logged in**  
sshd                                       **Never logged in**  
sysadmin         pts/1    10.0.2.2         Mon Dec  9 10:31:50 +1100 2013  
dbus                                       **Never logged in**  
joeblog          pts/2    10.0.2.2         Mon Dec  9 10:39:24 +1100 2013

Для просмотра содержимого текстовых журналов можно использовать команды «cat», «head» или «tail».

В приведенном ниже примере просматриваются последние 10 строк журнала /var/log/messages на Debian:

debian@debian:~$ sudo tail /var/log/messages

Вывод:

Dec 16 01:21:08 debian kernel: [    9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3  
Dec 16 01:21:08 debian kernel: [    9.584074] Bluetooth: BNEP filters: protocol multicast  
Dec 16 01:21:08 debian kernel: [    9.648220] Bridge firewalling registered  
Dec 16 01:21:08 debian kernel: [    9.696728] Bluetooth: SCO (Voice Link) ver 0.6  
Dec 16 01:21:08 debian kernel: [    9.696728] Bluetooth: SCO socket layer initialized  
Dec 16 01:21:08 debian kernel: [    9.832215] lp: driver loaded but no devices found  
Dec 16 01:21:08 debian kernel: [    9.868897] ppdev: user-space parallel port driver  
Dec 16 01:21:11 debian kernel: [   12.748833] [drm] Initialized drm 1.1.0 20060810  
Dec 16 01:21:11 debian kernel: [   12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11  
Dec 16 01:21:11 debian kernel: [   12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0

Демон rsyslog

Центром механизма журналирования является демон rsyslog. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux.

Конфигурационный файл rsyslog

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей.

Этот файл можно найти в rsyslog.d/50-default.conf в Ubuntu.

Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом.

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

Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения).

Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.

Вот отрывок из файла rsyslog.conf на CentOS:

# rsyslog v5 configuration file  
...  
...  
# Include all config files in /etc/rsyslog.d/  
IncludeConfig /etc/rsyslog.d/*.conf  
#### 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                                                 *  
# 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  
...  
...

Чтобы понять, что все это значит, нужно рассмотреть типы объектов, которые распознает Linux:

  • auth or authpriv: Сообщения, поступающие от сервисов авторизации и безопасности;
  • kern: сообщения ядра Linux;
  • mail: сообщения подсистемы почты;
  • cron: сообщения демона Cron;
  • daemon: сообщения от демонов;
  • news: сообщения подсистемы новостей сети;
  • lpr: сообщения, связанные с печатью;
  • user: сообщения пользовательских программ;
  • local0 до local7:Зарезервировано для локального использования.

Ниже приведен список приоритетов по возрастанию:

  • Debug: Отладочная информация от программ;
  • info: простое информационное сообщение – никакого вмешательства не требуется;
  • notice: состояние, которое может потребовать внимания;
  • warn: Предупреждение;
  • err: ошибка;
  • crit: критическое состояние;
  • alert: состояние, требующее немедленного вмешательства;
  • emerg: аварийное состояние.

Изучите следующую строку из файла:

cron.*              /var/log/cron

Она говорит rsyslog сохранять все сообщения, приходящие от демона cron, в файле /var/log/cron. Звездочка (*) поле точки значит, что зарегистрированы будут сообщения всех приоритетов. Аналогичным образом, если объект был определен звездочкой, это объединяет все источники.

Объекты и приоритеты могут быть связаны в несколькими способами.

Вид по умолчанию, когда после точки указан только один приоритет, значит, что будут охвачены все сообщения с таким или высшим уровнем приоритета. Таким образом, данное указание регистрирует все сообщения, приходящие от почтовой подсистемы с приоритетом «warn» и выше в специальном файле в /var/log:

mail.warn           /var/log/mail.warn

Такие параметры будут регистрировать все сообщения с таким же или высшим, чем warn, приоритетом и пропускать все остальное. То есть, сообщения с приоритетом err, crit, alert и emerg также будут внесены в файл.

Знак равности (=) после точки указывает регистрировать только сообщения с указанным приоритетом. То есть, если нужно регистрировать только сообщения от почтовой подсистемы с приоритетом info, указание будет таким:

mail.=info          /var/log/mail.info

Опять же, если нужно регистрировать все сообщения почтовой подсистемы, кроме сообщений с приоритетом  info, строка будет выглядеть так:

mail.!info          /var/log/mail.info

или так:

mail.!=info         /var/log/mail.info

В первом случае файл mail.info содержал бы все сообщения с приоритетом ниже info. Во втором случае он содержал бы все сообщения с приоритетом выше info.

Несколько объектов в одной строке нужно разделить запятой.

Несколько селекторов в одной строке также разделяются запятой.

Отмеченное звездочкой действие объединяет всех пользователей.

К примеру, об этом говорит запись в файле rsyslog.conf на CentOS:

# Everybody gets emergency messages *.emerg                                                 *

По возможности проверьте, что говорит rsyslog.conf на других системах Linux. Вот отрывок из Debian:

#  /etc/rsyslog.conf    Configuration file for rsyslog.  
#  
#           For more information see  
#           /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html  
...  
...  
auth,authpriv.*         /var/log/auth.log  
*.*;auth,authpriv.none      -/var/log/syslog  
#cron.*             /var/log/cron.log  
daemon.*            -/var/log/daemon.log  
kern.*              -/var/log/kern.log  
lpr.*               -/var/log/lpr.log  
mail.*              -/var/log/mail.log  
user.*              -/var/log/user.log  
#  
# Logging for the mail system.  Split it up so that  
# it is easy to write scripts to parse these files.  
#  
mail.info           -/var/log/mail.info  
mail.warn           -/var/log/mail.warn  
mail.err            /var/log/mail.err  
#  
# Logging for INN news system.  
#  
news.crit           /var/log/news/news.crit  
news.err            /var/log/news/news.err  
news.notice         -/var/log/news/news.notice

Как можно видеть, Debian сохраняет сообщения безопасности/авторизации всех уровней в /var/log/auth.log, в то время как CentOS делает это в /var/log/secure.

Конфигурации для rsyslog могут исходить также от других пользовательских файлов. Эти файлы пользовательских конфигураций, как правило, расположены в разных каталогах в /etc/rsyslog.d. Файл rsyslog.conf включает эти каталоги, используя директиву «$IncludeConfig».

Так это выглядит в Ubuntu:

#  Default logging rules can be found in /etc/rsyslog.d/50-default.conf  
....  
....  
$IncludeConfig /etc/rsyslog.d/*.conf  
Содержимое каталога /etc/rsyslog.d выглядит так:  
-rw-r--r-- 1 root root  311 Mar 17  2012 20-ufw.conf  
-rw-r--r-- 1 root root  252 Apr 11  2012 21-cloudinit.conf  
-rw-r--r-- 1 root root 1655 Mar 30  2012 50-default.conf

Теперь сохранять сообщение в журнал необязательно; сообщение можно переслать консоли пользователя. В таком случае, поле действия будет содержать имя пользователя. Если сообщение нужно отправить нескольким пользователям, их имена нужно разделить запятыми. Если же сообщение нужно распространить между всеми пользователями, в поле действия вносится символ *.

Будучи частью сетевой операционной системы, демон rsyslog может не только хранить зарегистрированные сообщения локально, но и передавать их на другие серверы Linux, а также действовать как репозиторий для других систем. Демон прослушивает сообщения через UDP-порт 514. В приведенном ниже примере он пересылает критические сообщения ядра на сервер под названием «texas»:

kern.crit           @texas

Создание и тестирование сообщений

Теперь попробуйте сами создать сообщение.

Для этого нужно будет сделать следующее:

  • Задать спецификацию в файле /etc/rsyslog.conf;
  • Перезапустить демон rsyslog;
  • Проверить конфигурацию с помощью утилиты «logger».

В следующем примере внесены две строки в файл rsyslog.conf на CentOS. Как видите, обе они исходят от объекта local4 и имеют разные приоритеты.

[root@TestLinux ~]# vi /etc/rsyslog.conf  
....  
....  
# New lines added for testing log message generation  
local4.crit                                             /var/log/local4crit.log  
local4.=info                                            /var/log/local4info.log`

Затем нужно перезапустить сервис, чтобы обновить данные файла:

`[root@TestLinux ~]# /etc/init.d/rsyslog restart  
Shutting down system logger:                               [  OK  ]  
Starting system logger:                                    [  OK  ]  
[root@TestLinux ~]#`

Теперь нужно вызвать приложение logger, чтобы создать сообщение:

`[root@TestLinux ~]# logger -p local4.info " This is a info message from local 4"`

Каталог /var/log показывает два новых сообщения:

`...  
...  
-rw-------  1 root root      0 Dec  9 11:21 local4crit.log  
-rw-------  1 root root     72 Dec  9 11:22 local4info.log

Размер local4info.log не равен нулю, а это значит, что сообщение было записано:

[root@TestLinux ~]# cat /var/log/local4info.log  
Dec  9 11:22:32 TestLinux root:  This is a info message from local 4

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

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

Linux использует понятие «ротации» журналов вместо их очистки или удаления. При ротации создается новый каталог, а старый переименуется и при необходимости сжимается. Таким образом, журналы имеют несколько старых версий. Эти файлы будут возвращаться в течение определенного периода времени в виде так называемых backlog-ов. Как только будет получено определенное количество backlog-ов, новая ротация удалит самый старый журнал.

Ротация выполняется при помощи утилиты «logrotate».

Конфигурационный файл logrotate

Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.

Вот что находится в данном файле на Debian:

debian@debian:~$ 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  
# uncomment this if you want your log files compressed  
#compress  
# packages drop log rotation information into this directory  
include /etc/logrotate.d  
# no packages own wtmp, or btmp -- we'll rotate them here  
/var/log/wtmp {  
missingok  
monthly  
create 0664 root utmp  
rotate 1  
}  
/var/log/btmp {  
missingok  
monthly  
create 0660 root utmp  
rotate 1  
}  
# system-specific logs may be configured here

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

Файлы wtmp и btmp являются исключениями. wtmp отслеживает вход в систему, а btmp содержит информацию о неудавшихся попытках входа. Эти журнальные файлы ротируются каждый месяц, и ошибки не возвращаются, если можно найти один из предыдущих файлов wtmp или btmp.

Пользовательские конфигурации ротации журналов содержатся в каталоге «etc/logrotate.d». также они включены в logrotate.conf с помощью директивы include. К примеру, Debian показывает такое содержание данного каталога:

debian@debian:~$ ls -l /etc/logrotate.d  
total 44  
-rw-r--r-- 1 root root 173 Apr 15  2011 apt  
-rw-r--r-- 1 root root  79 Aug 12  2011 aptitude  
-rw-r--r-- 1 root root 135 Feb 24  2010 consolekit  
-rw-r--r-- 1 root root 248 Nov 28  2011 cups  
-rw-r--r-- 1 root root 232 Sep 19  2012 dpkg  
-rw-r--r-- 1 root root 146 May 12  2011 exim4-base  
-rw-r--r-- 1 root root 126 May 12  2011 exim4-paniclog  
-rw-r--r-- 1 root root 157 Nov 16  2010 pm-utils  
-rw-r--r-- 1 root root  94 Aug  8  2010 ppp  
-rw-r--r-- 1 root root 515 Nov 30  2010 rsyslog  
-rw-r--r-- 1 root root 114 Nov 26  2008 unattended-upgrades

Содержание rsyslog показывает, как вернуть логи в исходное состояние:

debian@debian:~$ cat /etc/logrotate.d/rsyslog  
/var/log/syslog  
{  
rotate 7  
daily  
missingok  
notifempty  
delaycompress  
compress  
postrotate  
invoke-rc.d rsyslog reload > /dev/null  
endscript  
}  
/var/log/mail.info  
/var/log/mail.warn  
/var/log/mail.err  
/var/log/mail.log  
/var/log/daemon.log  
/var/log/kern.log  
/var/log/auth.log  
/var/log/user.log  
/var/log/lpr.log  
/var/log/cron.log  
/var/log/debug  
/var/log/messages  
{  
rotate 4  
weekly  
missingok  
notifempty  
compress  
delaycompress  
sharedscripts  
postrotate  
invoke-rc.d rsyslog reload > /dev/null  
endscript  
}

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

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

Тестирование ротации

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

Чтобы продемонстрировать, как это работает, ниже приведен неполный список журнальных файлов в каталоге /var/log на CentOS:

[root@TestLinux ~]# ls -l /var/log  
total 800  
...  
-rw-------  1 root root    359 Dec 17 18:25 maillog  
-rw-------. 1 root root   1830 Dec 16 16:35 maillog-20131216  
-rw-------  1 root root  30554 Dec 17 18:25 messages  
-rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216  
-rw-------  1 root root    591 Dec 17 18:28 secure  
-rw-------. 1 root root   4187 Dec 16 16:41 secure-20131216  
...  
...

Неполное содержимое файла logrotate.conf выглядит так:

[root@TestLinux ~]# 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  
...  
...

Затем запустите команду logrotate:

[root@TestLinux ~]# logrotate -fv /etc/logrotate.conf

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

[root@TestLinux ~]# ls -l /var/log/mail*  
-rw-------  1 root root    0 Dec 17 18:34 /var/log/maillog  
-rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216  
-rw-------  1 root root  359 Dec 17 18:25 /var/log/maillog-20131217  
[root@TestLinux ~]# ls -l /var/log/messages*  
-rw-------  1 root root    148 Dec 17 18:34 /var/log/messages  
-rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216  
-rw-------  1 root root  30554 Dec 17 18:25 /var/log/messages-20131217  
[root@TestLinux ~]# ls -l /var/log/secure*  
-rw-------  1 root root    0 Dec 17 18:34 /var/log/secure  
-rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216  
-rw-------  1 root root  591 Dec 17 18:28 /var/log/secure-20131217  
[root@TestLinux ~]#

Как можно видеть, все три новых журнала были созданы. Почтовый журнал и журнал безопасности все еще пусты, но новый журнал сообщений уже содержит некоторые данные.


CentOS
логи
Ubuntu
logger
rsyslog

Системный журнал по умолчанию обычно содержит наибольший объем информации о вашей системе Ubuntu. Он расположен в / var / log / syslog и может содержать информацию, которой нет в других журналах.

Откройте окно терминала и введите команда cd / var / log. Теперь введите команду ls, и вы увидите журналы, размещенные в этом каталоге (рисунок 1).

Где находится файл журнала ошибок в Linux?

Для поиска файлов вы используете синтаксис команды: grep [параметры] [шаблон] [файл] , где «шаблон» — это то, что вы хотите найти. Например, чтобы найти слово «ошибка» в файле журнала, вы должны ввести grep ‘error’ junglediskserver. log, и все строки, содержащие слово «ошибка», будут выведены на экран.

Как просмотреть файл журнала?

Поскольку большинство файлов журнала записываются в виде обычного текста, его можно открыть с помощью любого текстового редактора. По умолчанию Windows будет использовать Блокнот чтобы открыть файл LOG, дважды щелкнув по нему. У вас почти наверняка есть приложение, уже встроенное или установленное в вашей системе для открытия файлов LOG.

Как проверить системные журналы?

Для просмотра журнала безопасности

  1. Откройте средство просмотра событий.
  2. В дереве консоли разверните Журналы Windows и щелкните Безопасность. На панели результатов перечислены отдельные события безопасности.
  3. Если вы хотите просмотреть дополнительные сведения о конкретном событии, в области результатов щелкните событие.

Как найти ошибку журнала?

Windows 7:

  1. Нажмите кнопку «Пуск» в Windows> Введите событие в поле «Поиск программ и файлов».
  2. Выберите Просмотр событий.
  3. Перейдите в Журналы Windows> Приложение, а затем найдите последнее событие с «Ошибка» в столбце «Уровень» и «Ошибка приложения» в столбце «Источник».
  4. Скопируйте текст на вкладке Общие.

Как проверить файл на наличие ошибок?

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

  1. Проверьте файлы журнала на наличие сообщений об ошибках. Изучите errlog. сначала войдите.
  2. Если указано, проверьте дополнительные файлы журнала на наличие сообщений об ошибках.
  3. Определите ошибки, связанные с вашей проблемой.

Что такое файл журнала в Linux?

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

Как проверить журнал ошибок сервера?

Имя и расположение журнала задаются командой ErrorLog, а расположение файлов журнала доступа apache по умолчанию: RHEL / Red Hat / CentOS / Fedora Linux Расположение файла журнала доступа Apache — / var / log / httpd / error_log. Расположение файла журнала доступа Debian / Ubuntu Linux Apache — / var / log / apache2 / error. журнал.

Как проверить логи Splunk?

Журналы приложений доступны через Splunk. Чтобы начать новый поиск, откройте меню запуска на портале платформы ЗДЕСЬ и нажмите Журналы (см. пункт меню 3 на рисунке 1). Откроется домашняя страница Splunk, и вы можете начать с ввода поискового запроса и начала поиска.

Как просмотреть журналы Dmesg?

Тем не менее вы можете просматривать журналы, хранящиеся в Файлы ‘/ var / log / dmesg’. Если вы подключите какое-либо устройство, будет генерироваться вывод dmesg.

Оригинал:

«Ubuntu Hacks: Chapter 8 — Administration»

Авторы: Кайл Ранкин, Джонатан Оксер, Билл Чайлдерс (Kyle Rankin, Jonathan Oxer, Bill Childers)

Дата публикации: June 2006

Перевод: Н.Ромоданов

Дата перевода: октябрь 2010 г.

Совет # 82: Проверяем вахтенный журнал

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

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

Обычная настольная система, даже когда в ней все в порядке, создает каждый день удивительно большое количество журналов. Когда вы подключаетесь к сети, подключаете новое устройство, входите в систему или выполняете ряд других вещей, система фиксирует ваши действия в журналах.
Большинство системных журналов находятся в директории /var/log. Информация в некоторых
журналах дублирует друг-друга; например, сообщения, идущие от демонов, будут отображаться как
в журнале daemon.log, так и в журнале syslog. Вот некоторые из журналов, которые
вы найдете в директории /var/log:

syslogsyslog является основным системным журналом и в нем сохраняются сообщения демонов и других программ, работающих в системе, например, dhclient, cron, init, xscreensaver, а также некоторые сообщения ядра. Этот журнал — первое место, откуда надо начинать просмотр при попытке отследить типичные системные ошибки.

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

kern.log — Как и в dmesg, в этом журнале содержатся сообщения ядра; но, его преимущество в том, что указывается время выдачи сообщения.

Xorg.?.log — В журналах Xorg содержится очень подробная выходная информация Xorg, номер журнала указывает номер дисплея, на котором работает сессия Xorg. По умолчанию сессия Xorg работает на дисплее 0, так что, в основном, чтобы отследить ошибки в Xorg, вам нужно смотреть журнал Xorg.0.log.

messages — Этот журнал содержит некоторые сообщения ядра и журнальные записи некоторых
системных программ. Например, gconfd и некоторые другие программы выдают сюда свои сообщения.

daemon.log — Здесь вы найдете те же самые сообщения демонов, которые вы, как правило,
вы найдете в syslog, но без сообщений ядра и других систем, которые записываются в syslog.

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

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

apache/ — Если у вас в вашей системе установлен веб сервер Apache, то в директории /var/log/apache будут находится журналы ccess_log, error_log и все другие основные журналы сервера Apache.

cups/ — CUPS это система печати Ubuntu. В этом директории находятся разнообразные журналы сервиса CUPS, так что здесь ищите
сообщения при решении проблем с печатью в системе.

gdm/ — GDM является графическим менеджером входа в систему в GNOME. Если вы заметили какие-либо проблемы с экраном входа в систему, смотрите журналы, находящиеся в этом директории.

Просмотр журналов

Теперь, вы знаете, где искать информацию, и есть несколько способов, которыми можно практически воспользоваться для просмотра журналов. В Ubuntu есть замечательный графический инструмент для просмотра журнала, который называется System Log Viewer. Чтобы запустить эту программу, выберите System → Administration → System Log (Система → Администрирование → Системный журнал). Окно, открываемое по умолчанию, состоит из левой боковой панели со списком системных журналов, которые вы можете открыть, и основной части, в котором показывается содержимое выбранного журнала. По умолчанию в System Log Viewer указан только журнал syslog, но можно нажать кнопку Log → Open (Журнал → Открыть) и добавить журнал в список, расположенный на боковой панели (рис. 8-14).

Ubuntu Hacks. Окно программы System Log Viewer

Рис.8-14. Окно программы System Log Viewer, открываемое по умолчанию

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

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

$ less /var/log/syslog

чтобы открыть журнал syslog (можно заменить этот файл и указать путь
к другому файлу, который вы хотите открыть). Вы можете воспользоваться клавишами со стрелками для перемещения вверх и вниз по файлу, или вы можете нажимать клавишу G для перехода к самому концу файла, или клавишу g – для перехода к самому началу файла. Для того, чтобы выполнить поиск в журнале по ключевому слову, введите символ «/», за которым укажите ключевое слово для поиска. В терминале будут выделены все совпадения с ключевым словом, и вы можете нажать клавишу n для перехода к следующему совпадению, либо – клавишу N для перехода к предыдущему совпадению. Нажмите клавишу F, чтобы программа less продолжила обновление журнала по мере добавления в него новых строк (почти также, как команда tail -f работает с файлами).

Предостережение

У некоторых может возникнуть соблазн для открытия журнала просто использовать редактор vi, однако имейте в виду, что vi, когда он открывает файл, кэширует на диске весь файл. Если журнал небольшой, то проблем не возникает, но когда вы открываете журнал Apache размером в 2 ГБ, вы можете заполнить все место, оставшееся на диске! Программа less не кэширует весь файл так, как это делает vi, так что это более безопасный выбор для больших журнальных файлов.

Также для работы с журналами очень полезным инструментом является grep. Grep в качестве аргумента получает шаблон и ищет в файле совпадения с этим шаблоном. Например:

$ grep dhclient /var/log/syslog

вернет все записи, в которых содержится слово «dhclient». Grep
особенно полезен для работы с журналами Xorg, поскольку все предупреждения и ошибки в этих журналах предваряются префиксами WW и EE, соответственно. Для того, чтобы из файла Xorg.0.log выделить предупреждения и ошибки, введите следующее:

$ grep -E '(WW|EE)' /var/log/Xorg.0.log

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

Подсказка

Некоторые журналы, которые вы хотите просмотреть, могут быть сжаты
для удобства ротации журналов. В этом случае просто воспользуйтесь zless и zgrep вместо соответственно less и grep.


Если вам понравилась статья, поделитесь ею с друзьями:


This tutorial explains the basic administration of a Linux server through system
logs. A system log is a file that contains information about the events that
happened on the system during runtime.

In this article, you will learn the following Linux logging basics:

  • Where the Linux log files are stored, how are they formatted, and how to read them.
  • How to read the most important logs (such as syslog).
  • How to configure the Ubuntu syslog daemon.
  • What Linux log rotation is all about and how to use the logrotate utility.

Prerequisites

Before proceeding with the rest of this tutorial, ensure that you have a basic
knowledge of working with the Linux command line. While many of the concepts
discussed in this article are general applicable to all Linux distributions,
we’ll be demonstrating them in Ubuntu only so ensure to set up an Ubuntu 20.04
server that includes a non-root user with sudo access.

🔭 Want to centralize and monitor your Linux logs?

Head over to Logtail and start ingesting your logs in 5 minutes.

Step 1 — Finding Linux system logs

All Ubuntu system logs are stored in the /var/log directory. Change into this
directory in the terminal using the command below:

You can view the contents of this directory by issuing the following command:

You should see a similar output to the following:

Output

alternatives.log  auth.log       btmp            cloud-init-output.log  dmesg    dpkg.log  journal/  landscape/  private/  ubuntu-advantage-license-check.log  ubuntu-advantage-timer.log  unattended-upgrades/
apt/              bootstrap.log  cloud-init.log  dist-upgrade/          dmesg.0  faillog   kern.log  lastlog     syslog    ubuntu-advantage.log                ufw.log                     wtmp

Let’s look at a few of the essential system log files that may be present in the
/var/log directory and what they contain:

  • /var/log/syslog: stores general information about any global activity in the
    system.
  • /var/log/auth.log: keeps track of all security-related actions (login,
    logout, or root user activity).
  • /var/log/kern.log: stores information about events originating from the
    Linux kernel.
  • /var/log/boot.log: stores system startup messages.
  • /var/log/dmesg: contains messages related to device drivers.
  • /var/log/faillog: keeps track of failed logins, which comes in handy when
    investigating attempted security breaches.

The /var/log directory is also used to store various application logs. For
example, if your distribution is bundled with Apache or MySQL, or installed
later, their log files will also be found here.

Step 2 — Viewing Linux log file contents

Log files contain a large amount of information that are useful for monitoring
or analyzing activities performed by the system or a specific application.
Therefore, a Linux server administrator must learn the art of reading and
understanding the various messages present in log files to effectively diagnose
or troubleshoot an issue.

Before we can read log files, we ought to know how they are formatted. Let’s
review two basic approaches to log file formatting and storage: plain text and
binary files.

Plaintext log files

These logs are plain text files with a standardized content format. Ubuntu uses
a log template called
RSYSLOG_TraditionalFileFormat.
This log format consists of four main fields with a space delimiter:

  1. The timestamp indicates the time when a log entry was created in the
    format MMM dd HH:mm:ss (e.g. Sep 28 19:00:00). Notice that this format
    does not include a year.
  2. Hostname is the host or system that originally create the message.
  3. Application is the application that created the message.
  4. Message contains the actual details of an event.

Let’s go ahead and review some log files in the plaintext format. Run the
command below to print the contents of the /var/log/syslog file with the
tail utility:

sudo tail /var/log/syslog

This outputs the last 10 lines of the file:

Output

Mar 23 12:38:09 peter dbus-daemon[1757]: [session uid=1000 pid=1757] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.1' (uid=1000 pid=1754 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Mar 23 12:38:09 peter systemd[1743]: Starting Tracker metadata database store and lookup manager...
Mar 23 12:38:09 peter dbus-daemon[1757]: [session uid=1000 pid=1757] Successfully activated service 'org.freedesktop.Tracker1'
Mar 23 12:38:09 peter systemd[1743]: Started Tracker metadata database store and lookup manager.
Mar 23 12:38:40 peter tracker-store[359847]: OK
Mar 23 12:38:40 peter systemd[1743]: tracker-store.service: Succeeded.
Mar 23 12:39:01 peter CRON[359873]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Mar 23 12:39:23 peter systemd[1]: Starting Clean php session files...
Mar 23 12:39:23 peter systemd[1]: phpsessionclean.service: Succeeded.
Mar 23 12:39:23 peter systemd[1]: Finished Clean php session files.

You’ll notice that that each record in this file is formatted in the manner
described earlier. For example, the last record has its timestamp as Mar 23
12:39:23
, hostname as peter, application as systemd[1] and message as
Finished Clean php session files.

If you want to view the entire log file, you can use the cat utility or any
text editor such as nano or vim.

Binary log files

While plaintext is the dominant storage format for log files, you will also
encounter binary log files that cannot be read with a normal text editor. The
/var/log directory contains multiple binary files that are related to the user
authorization:

  • /var/log/utmp: tracks users that are currently logged into the system.
  • /var/log/wtmp: tracks previously logged in users. It contains a past data
    from utmp.
  • /var/log/btmp: tracks failed login attempts.

For these binary logs, special command-line tools are used to display the
relevant information in human-readable form. For example, to review the contents
of the /var/log/utmp file, run the who utility with -H option (this option
causes column labels to be printed in the output table):

You’ll see the program’s output appear on the screen:

Output

NAME   LINE         TIME             COMMENT
george pts/0        2021-03-21 15:29 (2001:67c:1220:80c:b1:a84e:69ee:f530)
willie pts/1        2021-03-21 07:20 (adsl-dyn22.78-98-29.t-com.sk)
bonnie pts/2        2021-03-21 10:31 (2001:67c:1220:80c:b1:a84e:69ee:f530)
peter  pts/6        2021-03-21 14:37 (100.64.97.50)
...

The output above describes all the currently logged in users, the time of login
and their host machine’s IP address.

You can also review the contents of the /var/log/wtmp binary file through the
last command as shown below:

You’ll see the program’s output appear on the screen:

Output

peter    :1           Sat Mar 13 08:06   still logged in
reboot   system boot  Sat Mar 13 08:06   still running
peter    :1           Fri Mar 12 07:42 - down  (1+00:22)
reboot   system boot  Fri Mar 12 07:42 - 08:05 (1+00:23)
peter    :1           Sun Mar  7 11:20 - down  (4+20:21)
reboot   system boot  Sun Mar  7 11:20 - 07:41 (4+20:21)
peter    :1           Fri Mar  5 08:02 - crash (2+03:17)
reboot   system boot  Fri Mar  5 08:01 - 07:41 (6+23:39)
peter    :0           Tue Mar  2 08:38 - crash (2+23:23)
reboot   system boot  Tue Mar  2 08:38 - 07:41 (9+23:03)
peter    :1           Thu Feb 25 11:44 - down  (4+20:53)
reboot   system boot  Thu Feb 25 11:44 - 08:37 (4+20:53)

wtmp begins Thu Feb 25 11:43:23 2021

The output shows a table where the first column refers to the user name (the
pseudo-user reboot is recorded each time when the system is rebooted). The third
field refers to the login timestamp, and the last column shows the session
duration.

To review the /var/log/btmp file (containing failed login attempts), execute
the lastb command with sudo privileges:

You’ll see the program’s output appear on the screen:

Output

falcon   tty3                  Thu Feb 12 07:10 - 07:10  (00:00)
ruby     tty1                  Thu Feb 12 07:09 - 07:09  (00:00)
sergio   tty1                  Thu Feb 12 07:09 - 07:09  (00:00)

btmp begins Thu Feb 25 11:43:32 2021

The output shows users that failed to login with the corresponding timestamp.

Step 3 — Examining the syslog deamon configuration

All system logs are created and maintained by a background process called a
daemon. The traditional Linux daemon for logging is syslogd. However, Ubuntu
20.04 uses a daemon called rsyslogd which is a superset of syslogd. It uses
a special configuration file (/etc/rsyslog.conf) that specifies the logging
rules.

Go ahead and print the contents of the /etc/rsyslog.conf file with the cat
command:

This command prints the entire content of this configuration file, but we’re
only going to show a truncated output here:

Output

[label /etc/rsyslog.conf]
. . .

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages
$RepeatedMsgReduction on

#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

This file contains a lot of information, but we’ll focus on two configuration
details. Firstly, a variable called $ActionFileDefaultTemplate defines the
syslog record format as described in Step 2. You can change the value of this
variable if the default log format is unsuitable for you. Secondly, the last
line in the file defines a variable called $IncludeConfig that specifies the
directory for additional configuration files.

In Ubuntu, all additional Rsyslog rules are placed in the
/etc/rsyslog.d/50-default.conf file by default. Go ahead and examine the
contents of this file with the head utility (the -n 15 option specifies that
only the first 15 lines should be printed):

head -n 15 /etc/rsyslog.conf/50-default.conf

You’ll see the program’s output appear on the screen:

Output

#  Default rules for rsyslog.
#
#           For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*         /var/log/auth.log
*.*;auth,authpriv.none      -/var/log/syslog
#cron.*             /var/log/cron.log
#daemon.*           -/var/log/daemon.log
kern.*              -/var/log/kern.log
#lpr.*              -/var/log/lpr.log
mail.*              -/var/log/mail.log
#user.*             -/var/log/user.log

The output contains rsyslogd configuration rules. Each non-empty line (or line
that does not start with the # character) defines a rule. The rule definition
starts with a selector followed by one or more spaces and an action field:

  • The selector specifies the facility with a corresponding priority. For
    example, the * selector refers to all facilities or priorities.
  • The action field of a selector usually references a log file.

Step 4 — Rotating log files in Linux

The size of log file must be controlled because they always grow over time. Each
system has limited resources and logs that are too large can lead to performance
and memory problems, not to mention the loss of storage space. Linux
distributions typically solve this problem through the concept of log rotation
which continuously repeats the following actions:

  1. Instead of continuously writing to log file as it grows larger, the file name
    is changed to one with a version suffix, and creates a brand new file is
    created for new log entries. This means a log file has multiple backups which
    are optionally compressed.
  2. When the backup files reaches a specified number, the system deletes the
    oldest ones.

Let’s view an example of rotating log files in Linux. Execute the ls command
with following options:

ls -l -h -t /var/log/syslog*

The -l option outputs a listing that includes various metadata about a file,
the -h option prints the file size in human-readable form, and the -t option
sorts the listing by modification time (newest first). The /var/log/syslog*
argument specifies that only files in the /var/log directory with the syslog
prefix should be included in the output.

You’ll see the program’s output appear on the screen:

Output

-rw-r----- 1 syslog adm  47K mar 30 09:49 /var/log/syslog
-rw-r----- 1 syslog adm 3,5G mar 30 07:45 /var/log/syslog.1.gz
-rw-r----- 1 syslog adm 1,6M mar 29 10:06 /var/log/syslog.2.gz
-rw-r----- 1 syslog adm  29K mar 28 07:49 /var/log/syslog.3.gz
-rw-r----- 1 syslog adm  54K mar 27 08:08 /var/log/syslog.4.gz
-rw-r----- 1 syslog adm 6,4M mar 26 07:35 /var/log/syslog.5.gz
-rw-r----- 1 syslog adm  31K mar 25 08:01 /var/log/syslog.6.gz

This output describes all the versions of the syslog file. Typically, it is
the biggest log file on the system because, as explained earlier, it records
almost every event that occurs in the system. The older versions are labelled
with a version suffix (e.g. syslog.6.gz is the oldest syslog backup).

Notice that the backup files are all compressed with the standard GNU zip
compression algorithm. (as evidenced by the .gz extension). This helps with
space savings since log files can grow to the size of gigabytes (in our example
the biggest file is 3.5 GB). You’ll also notice that these files cover a time
interval of only six days.

Step 5 — Configuring the logrotate daemon

Log rotation is maintained by a system daemon called logrotate. Similar to the
rsyslogd utility, this daemon uses a special configuration file called
logrotate.conf in the /etc directory.

Go ahead and display the contents of the logrotate config file with cat
utility:

This command prints the entire contents of the configuration file to the screen:

Output

# see "man logrotate" for details
# rotate log files weekly
weekly

# use the adm group by default, since this is the owning group
# of /var/log/syslog.
su root adm

# 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

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

# system-specific logs may be also be configured here.

The output describes the global configuration for logrotate. In our example,
the log files are rotated weekly, the system keeps four rotation backups, and
compression is turned off. However, this is the most general configuration for
any log. We can also set up a more specific configuration for a particular log
file. In Ubuntu, the configuration for specific logs are placed in the
/etc/logrotate.d directory by default (you’ll notice the presence of this
directory in /etc/logrotate.conf).

Let’s view the contents of the /etc/logrotate.d directory by executing the
ls command:

The output below describes all the utilities that have a specific log rotation
config:

Output

alternatives  bootlog      dpkg               ubuntu-advantage-tools
apache2       btmp         ppp                ufw
apport        certbot      rsyslog            unattended-upgrades
apt           cups-daemon  speech-dispatcher  wtmp

You’ll notice that the rsyslog daemon has its own log rotation configuration
file. Go ahead and display the first 15 lines of the rsyslog file with the
head utility:

head -n 15 /etc/logrotate.d/rsyslog

You’ll see the following output on the screen:

Output

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

/var/log/mail.info
/var/log/mail.warn

This output shows that the syslog file is rotated daily, and that seven
compressed backups are kept before older ones are deleted.

You can force logrotate to rotate a log file immediately by executing
following the command:

sudo logrotate -fv /etc/logrotate.conf

The -f option forces immediate rotation and the -v option turns on verbose
mode (it will display messages during rotation). The execution of this command
shows the following output (truncated to save space):

Output

reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file alternatives
reading config file apache2
reading config file apport
reading config file apt
reading config file bootlog
reading config file btmp
reading config file certbot
reading config file cups-daemon
reading config file dpkg
reading config file ppp
reading config file rsyslog
reading config file speech-dispatcher
reading config file ubuntu-advantage-tools
reading config file ufw
reading config file unattended-upgrades
reading config file wtmp
. . .

The beginning of the output shows that the logrotate daemon reads all its
configuration files first before proceeding. The entire output is very long
because it prints every single detail of the rotation process.

Conclusion

In this tutorial, you’ve learnt the basics of system logs in Linux and how to
read and understand them. We discussed where the logs are typically placed and
the different log formats you will likely encounter. We also covered the
rsyslogd utility, which is responsible for maintaining log files in Ubuntu
before discussing log rotation and how to use the logrotate utility to keep
log files small and manageable. To learn more about all the utilities described
in this article, explore the
Rsyslog server article and the
Logrotate article in
the Logging guides.

Thanks for reading!

Centralize all your logs into one place.

Analyze, correlate and filter logs with SQL.

Create actionable

dashboards.

Share and comment with built-in collaboration.

Got an article suggestion?
Let us know

Share on Twitter

Share on Facebook

Share via e-mail

Next article

How to Use Logrotate to Manage Log Files in Linux

Learn how to use the Logrotate utility in Linux-based systems to set up automatic compression and deletion of older log records

Licensed under CC-BY-NC-SA

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

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

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

Важно отметить, что Linux сохраняет свои файлы журнала в /var/log каталоге в текстовом формате.

Содержание

  1. Просмотр системного входа в систему Ubuntu
  2. Просмотрите файлы журнала через журналы Gnome
  3. Через средство просмотра файла журнала
  4. Просмотрите файлы журнала через терминал
  5. Настройка dmesg вывод
  6. Откройте Log File с Командой кошки
  7. Запись в системный журнал

Просмотр системного входа в систему Ubuntu

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

  • (Графическая) утилита Gnome Logs
  • (Графическая) утилита Log File Viewer
  • Терминал Linux (командная строка)

Просмотрите файлы журнала через журналы Gnome

‘Журналы’ являются утилитой по умолчанию, которая идет с последними версиями Ubuntu, например, Ubuntu 18.04 LTS (Бионический Бобр). Для доступа к нему,

Тип Входит в систему тире Ubuntu:

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

Нажмите на вкладку System для просмотра системных журналов:

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

  • Отобразите содержание журнала путем нажатия на него.
  • Ищите журнал путем нажатия на значок поиска и затем обеспечения ключевых слов в панели поиска. Панель поиска также предлагает много фильтров, которые можно применить для точного определения то, Что (Выбирают поле Journal для фильтрации журналов согласно ему) и Когда (Выбирают диапазон метки времени записей в журнале, которые покажут), Вы хотите видеть:
  • Можно также экспортировать журналы в файл путем нажатия кнопки экспорта, расположенной в главном правом углу окна Logs. Можно тогда сохранить файл журнала путем определения названия и местоположения.

Через средство просмотра файла журнала

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

Для доступа к Средству просмотра Файла журнала:

  • Введите средство просмотра журнала в тире Ubuntu

или

  • При установке этой программы через Ubuntu Software можно запустить его путем поиска его в Ubuntu Software следующим образом и затем нажатия кнопки Launch:

Средство просмотра Файла журнала появится следующим образом:

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

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

Для просмотра журнала для определенного приложения нажмите опцию Open из меню File. Следующее окно Open Log откроется для Вас для выбора журнала из:

Нажмите на файл журнала и нажмите Open. Вы теперь будете в состоянии видеть журналы от выбранного файла журнала в Средстве просмотра Файла журнала.

Просмотрите файлы журнала через терминал

Можно также просмотреть системные журналы через командную строку, т.е. Терминал Ubuntu.

Откройте Terminal и введите следующую команду:

Эта команда выбирает все сообщения от буфера ядра. Вы видите вывод следующим образом:

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

Настройка dmesg вывод

  • Для наблюдения сообщений в собственном темпе используйте следующую команду:

Эта команда отобразит только определенное количество сообщений на экран. Можно нажать Enter, чтобы переместиться в следующее сообщение или нажать Q для выхода из команды.

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

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

Терминал теперь отобразит только те сообщения, содержащие слово “ядро” в красном цвете.

Откройте Log File с Командой кошки

Команда dmesg открывает все журналы из/var/log каталога. Для открытия файла журнала от некоторого другого местоположения используйте следующую команду:

Пример:

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

cat |grep [keyword] [location]

И

Запись в системный журнал

Иногда мы должны записать пользовательские сообщения в наш системный журнал во время процесса поиска и устранения неисправностей. И Журнал Gnome и программы Средства просмотра Файла журнала создаются для отображения специализированного сообщения, что можно записать через Терминал.

Откройте Ubuntu Terminal и введите следующую команду:

logger "This is a custom message"

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

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

logger -t scriptname "This is a custom message"

Понравилась статья? Поделить с друзьями:
  • Ubuntu временная ошибка при разрешении ru archive ubuntu com
  • Ue33 pioneer ошибка
  • Ubuntu xrdp error
  • Ue22 ошибка pioneer как устранить
  • Ue на стиральной машине lg при отжиме как устранить ошибка