Размещение перед именем файла символа канала (|) позволит использовать fifo (first in - first out, первый пришел - первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp , и открыт UTP-порт 514)

Список пользователей

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

Все зарегистрированные пользователи

Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).

Пример несложного syslog.conf:

# Все сообщения ядра выдавать на консоль. #kern.* /dev/console # Все логи уровня info или выше, кроме сообщений электронной почты, а так же # не логировать сообщения аутентификации и сообщений демона cron! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать в отдельный файл. mail.* -/var/log/maillog # Логировать сообщения планировщика в файл /var/log/cron cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно получить # все пользователи системы *.emerg * # Сохранять сообщения новостей уровня crit и выше в отдельный файл. uucp,news.crit /var/log/spooler # Сохранять сообщения загрузки в boot.log local7.* /var/log/boot.log

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

  • строки, начинающиеся с #, и пустые строки игнорируются.
  • Символ * может использоваться для указания всех категорий или всех приоритетов.
  • Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
  • Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак! , чтобы показать, что действие не должно применяться, начиная с этого уровня и выше . Подобным образом, перед приоритетом можно поставить знак = , чтобы показать, что правило применяется только к этому уровню, или != , чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

# Посылать все сообщения ядра в /var/log/kernel. # Посылать все сообщения уровня critical и higher на удаленную машину sysloger и на консоль # Посыласть все сообщения уровня info, notice и warning в /var/log/kernel-info # kern.* /var/log/kernel kern.crit @sysloger kern.crit /dev/console kern.info;kern.!err /var/log/kernel-info # Посылать все сообщения почтовой системы, кроме уровня info в /var/log/mail. mail.*;mail.!=info /var/log/mail

Я постарался максимально понятно работу syslogd показать на схеме:

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog , однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian) .

Вот некоторые возможные параметры запуска демона syslogd:

  • -a /folder/socket - указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
  • -d - отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
  • -f имя-конфигурационного-файла . Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
  • -l список-хостов - задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name);
  • -m минут - запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
  • -p socket - задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
  • -r - разрешение принимать сообщения от удаленных хостов;
  • -x - запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
  • -v - показать версию и закончить работу

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid .

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd .

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

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

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate , которая обычно выполняется демоном cron . О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

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

# сначала заданы параметры "по-умолчанию" (глобальные опции) # обновлять файлы журнала еженедельно weekly # хранить архив логов за 4 последние недели rotate 4 # создавать новый (пустой) файл после ротации (обновления) create # раскомментируйте, если желаете, чтобы сохраненные файлы сжимались #compress # включить настройки ротации из указанного каталога include /etc/logrotate.d # не хранить wtmp, или btmp -- настройки ротации данных журналов следующие: /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0664 root utmp rotate 1 } # специфичные системные журналы могут быть настроены ниже

Глобальные опции размещаются в начале файла logrotate.conf . Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.

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

Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. Пример:

/var/log/messages { rotate 5 mail logadmin@sysloger size 100k postrotate /usr/bin/killall -HUP syslogd endscript }

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры , задаваемые в конфигурационном файле logrotate.conf:

  • compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
  • compresscmd (задает программу сжатия, по умолчанию - gzip)
  • uncompresscmd (задает программу разжатия, по умолчанию - ungzip)
  • compressext (задает суффикс для сжатых файлов)
  • compressoptions (задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip)
  • copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
  • create [права-доступа владелец группа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами - права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
  • daily (смена версий в серии происходит ежедневно)
  • delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
  • errors email (кому направлять сообщения об ошибках)
  • extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
  • ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
  • include имя-файла | имя-директории (текстуально подставить файл или все файлы из указанной директории; не включаются поддиректории, специальные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
  • mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
  • mailfirst (посылать не удаляемую версию журнала, а первую)
  • maillast (посылать удаляемую версию журнала; действует по умолчанию)
  • missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
  • monthly (смена версий происходит ежемесячно)
  • olddir директория | noolddir (во время смены версий журнал перемещается в указанную директорию; д.б. на том же физическом устройстве)
  • postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии)
  • prerotate (все дальнейшие строчки до строки endscript исполняются перед процессом смены версии)
  • rotate число (сколько старых версий хранить; если 0, то ни одной)
  • size байт (смена версии происходит, если размер журнала превысил указанное число; можно использовать суффиксы "k" - килобайт - и "M" - мегабайт)
  • sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
  • tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак "плюс", то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, ",v", .swp и "~")
  • weekly (смена версий происходит еженедельно)

Изучение и мониторинг журналов

Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less , искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep :

# less /var/log/messages # grep "ppp" /var/log/messages | tail Dec 17 16:34:25 proxy pppd: Connection terminated. Dec 17 16:34:25 proxy pppd: Exit. Dec 17 16:35:57 proxy pppd: LCP terminated by peer (^P]kV^@

Компьютер может работать не постоянно и выключаться, допустим на ночь. Поэтому в /var/log/messages записи хранятся циклически от запуска компьютера к выключению, это можно заметить по сообщениям:

Дек 17 08:32:56 syslog-server syslogd 1.4-0: restart. Дек 17 08:32:56 syslog-server syslog: запуск syslogd succeeded Дек 17 08:32:56 syslog-server kernel: klogd 1.4-0, log source = /proc/kmsg started. Дек 17 08:32:56 syslog-server syslog: запуск klogd succeeded

Dec 17 08:32:56 syslog-server kernel: Kernel command line: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2 Dec 17 08:32:56 syslog-server kernel: Memory: 125652k/130560k available (1365k kernel code, 4200k reserved, 92k data, 236k init, 0k highmem) Dec 17 08:32:56 syslog-server kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02

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

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

# tail -f /var/log/messages | grep syslog-server Dec 17 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 Dec 17 16:46:09 syslog-server pppd: Script /etc/ppp/ip-up finished (pid 12552), status = 0x0 Dec 17 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 control connection started Dec 17 16:46:49 syslog-server pptpd: CTRL: Starting call (launching pppd, opening GRE) Dec 17 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл , который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы , имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

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

Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом.

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

Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP.

Подведем небольшой итог:

В линукс есть единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP - 514, а так же от "помощника" - демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном syslogd через правила в файле /etc/syslog.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически "обрезаются". Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком - cron.

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

С Уважением, Mc.Sim!

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 .

Authorization Log

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. - 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.

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

System manual page for the dmesg kernel ring buffer utility

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

System manual page for the grep pattern searching utility

System manual page for the head utility

System manual page for the kernel log daemon (klogd)

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

System manual page for the less paging utility

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

System manual page for the the logrotate utility

System manual page for the savelog log file saving utility

System manual page for the system log daemon (syslogd)

System manual page for the syslogd configuration file

System manual page for the tail utility

Managing Log files on a Linux System

Linux"s Log Files

All Linux systems generate systems logs that can be inspected to find information about your running system. These log files can contain a wealth of information from simple information messages to critical system issues. Most of the logging files that are created are in plain text. This means that it is very easy to view these using standard commands such as "more", "less", "cat", "head", "tail", "pg" or by using your preferred text editor such as "vi or vim".


By convention, most of the log files that are created are found under the directory "/var/log/". This is a standard area where system messages and logged/recorded. Depending on which Linux distribution you are using you will probably have a "message" file or a "syslog" file that contains recent activity. Logfiles are generally created by either a "syslogd" or "rsyslogd" logging demon. These demons are highly configurable and can filter messages into specified files. As well as handling local events, it is possible to log messages to remote servers dedicated to receiving these type of messages. It is quite common within larger organisations to have a dedicated syslog server. Some basic configuration options will be covered later. It is also common practice to have some form of log rotation process.

Below is a list of some of the more common log files that you will find. Some of these are distribution specific:


Log File Description
/var/log/messages Global system messages are logged here. (default logging area on some systems)
/var/log/syslog Global System messages are logged here. (default logging area on some systems)
/var/log/auth.log System Authorisation information, including user login information
/var/log/kern.log Kernel messages are logged here
/var/log/mail.log Contains logging information from your mail server
/var/log/boot.log System boot messages are logged here
/var/log/cups.log Printer related messages logged here
/var/log/wtmp Contains information relating to users logged onto your system
/var/log/samba Samba log files for smbd and nmbd. If configured can contain specific log files for users.
/var/log/dpkg.log Contains information from installations that use dpkg to install or remove a package
/var/log/zypper.log Contains messages from zypper package manager tool
/var/log/apt Contains information from package updates that use APT
/var/log/dmesg Contains Kernel ring buffer messages

Although the above is not an exhaustive view of all the files that can be found within the "/var/log" area. It does give you a rough idea of what is logged. It is important to remember that many third part products (software) will also write to this area. Often a sub-directory is created with various log information held within. Samba is a good example of this.

As mentioned earlier it is the "syslogd" or "rsyslogd" daemon that handles the majority of logging on your systems.

rsyslogd - logging utility

Rsyslogd is a reliable extended version of the syslogd service. Linux uses rsyslogd as its mechanism to record log files either in a central area or split into separate directories for clarity. It is also possible to send information to a dedicated logging server. Multiple processes may write to the same area without causing file locking. Simple commands can be used directly from scripts to write to this area.

Configuration Files

How rsyslogd behaves on your system is down to its configuration. This file is generally located in "/etc/rsyslog.conf". This file contains text which describes what should happen to messages when they are logged. It is here that you can specify specific directories for specific message types. Default logging rules are generally located under "/etc/rsyslog.d/"

Example of rsyslogd.conf under Ubuntu

/etc/rsyslog.conf


# Default logging rules can be found in /etc/rsyslog.d/50-default.conf ################# #### MODULES #### ################# $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 ########################### #### 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 files # $WorkDirectory /var/spool/rsyslog # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf

Hashes "#" are used to denote a comment or for commenting out a function that is not required.
Notice the last line $IncludeConfig /etc/rsyslog.d/*.conf . This is where we can specify custom rules/mappings.


# 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 # # 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 # # Some "catch-all" log files. # #*.=debug;\ # auth,authpriv.none;\ # news.none;mail.none -/var/log/debug #*.=info;*.=notice;*.=warn;\ # auth,authpriv.none;\ # cron,daemon.none;\ # mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg:omusrmsg:* # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole" utility. To use it, # you must invoke `xconsole" with the `-file" option: # # $ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you"ll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole

The default logging area is called "syslog", see below exert


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

What are Facilities and Levels?

Whenever the rsyslogd daemon receives a logging message, it acts based on the message type (Facility) and a Level (Priority). These mappings can be seen in your "/etc/syslog.conf" file or your included "/etc/syslog.d/*.conf" files.

Each entry within the configuration file can specify one or more facility/level selectors followed by an action. A selector consists of a facility or facilities followed by a single action. Action is normally the name of the directory and file that is to receive the messages into.

facility.level action

Example: mail.* -/var/log/mail - Here, "mail" is the facility, level is set to "*" and action is "/var/log/mail"

Facility

A facility represents the creator of the message, these normally consist of:

auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, local0 - local7, "* " signifies any facility

These facilities give us the ability to control where messages from certain sources are sent to. The facilities local0 - local7 are for use by your own scripts.

Level (Priority)

The level specifies the severity threshold. These can be: (lowest priority first)

debug, info, notice, warning, err, crit, alert, emerg .

On older systems you may see "warn, error or panic". A level of none will disable the associated facility. These priorities control the amount of detail that is sent to each logfile. A single period "." separates the facility from the level. Together these are known as the message selector . An asterisk "* " may be used to specify all facilities or levels. Similar to facilities, wildcards "*" can be used along with "none". Only one level or wildcard may be specified with each selector. The following modifiers may be used "= " and "! "

If you specify only one level within a selector without any modifiers, you are actually specifying that level plus all other priorities. For example the selector user.notice is actually saying all user related messages having a level of notice or higher will be sent to the specified action area. If you require only a level of "notice", then you will have to use the "= " modifier:

user.=notice - Now means any user related messages with a level priority of "notice" only will be sent to the relevant logging area.

If you use the "! " modifier, this will negate your level priority. So if we specified user.!notice is the equivalent of all user related messages with a level priority of "notice" or higher. You can also specify user.!=notice which specify all user related messages except for ones with the level priority of "notice".

Actions

The action section is the destination for the messages. The action can be a filename such as "/var/log/syslog" or a hostname or IP address prefixed with the "@" sign. The latter option is popular in large organisations and enterprises. Quite often security related messages may be sent to a central logging server for further scrutiny.

rsyslog.conf structures

As rsyslogd is an enhanced version of the syslogd it can handle the older legacy style constructs known as sysklogd . It also handles legacy versions of rsyslog. However, the true power of rsyslog comes into play when you use what is known as "RainerScript ". This is the new style format for rsyslog which can handle complex cases with ease. In the example below you can see old format entries along with newer entries that use "if - then" constructs for a more precise handling.

Example section of "/etc/rsyslog.conf taken from openSUSE


# # NetworkManager into separate file and stop their further processing # if ($programname == "NetworkManager") or \ ($programname startswith "nm-") \ then -/var/log/NetworkManager & ~ # # email-messages # mail.* -/var/log/mail mail.info -/var/log/mail.info mail.warning -/var/log/mail.warn mail.err /var/log/mail.err # # news-messages # news.crit -/var/log/news/news.crit news.err -/var/log/news/news.err news.notice -/var/log/news/news.notice

Message Testing with the logger command

logger is a shell command interface into the syslog module. Logger allows you to make entries directly into the system log. This is very useful when incorporated into a script or when you want to test your message selector and mappings.

In its simplest form we can issue logger "I am a test" . This message would then go to our default area (probably /var/log/syslog or /var/log/messages) depending on how you have configured your rules. You can also specify a priority using the "-p or --priority" option. Examples of logger inaction:


john@john-desktop:/var/log$ logger "I am a Test of logger" Mar 22 22:39:51 john-desktop kernel: [ 9588.319477] dev_remove_pack: edad0884 not found. Mar 22 22:45:01 john-desktop CRON: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Mar 22 22:47:31 john-desktop john: I am a Test of logger

Basic Logger Usage

Usage: logger Options: -d, --udp use UDP (TCP is default) -i, --id log the process ID too -f, --file log the contents of this file -h, --help display this help text and exit -n, --server write to this remote syslog server -P, --port use this UDP port -p, --priority Mark given message with this priority -s, --stderr output message to standard error as well -t, --tag mark every line with this tag -u, --socket write to this Unix socket -V, --version output version information and exit

Getting help with Rsyslog

The above is intended as an overview to the processes that takes place for logging of messages to occur. For further information you can issue "man rsyslogd" from your console for an overview of the many options. For further reading you can head to the main "rsyslog" website: www.rsyslog.com

dmesg

"dmesg" is a special command that stands for display message. dmesg will display the message buffer of the kernel. dmesg is very useful if you want to view the messages that flew past your screen quickly during the boot process. Another useful trick is to redirect the output from the dmesg command to a temporary file: dmesg > /tmp/temp.txt .

dmesg is also useful if you are having issues with an I/O device or a "USB" device. dmesg can be used in combination with the grep command to find exactly what you are looking for quickly: dmesg | grep -i usb

dmesg basic Overview

Usage: dmesg Options: -C, --clear clear the kernel ring buffer -c, --read-clear read and clear all messages -D, --console-off disable printing messages to console -d, --show-delta show time delta between printed messages -E, --console-on enable printing messages to console -f, --facility restrict output to defined facilities -h, --help display this help and exit -k, --kernel display kernel messages -l, --level restrict output to defined levels -n, --console-level set level of messages printed to console -r, --raw print the raw message buffer -s, --buffer-size buffer size to query the kernel ring buffer -T, --ctime show human readable timestamp (could be inaccurate if you have used SUSPEND/RESUME) -t, --notime don"t print messages timestamp -u, --userspace display userspace messages -V, --version output version information and exit -x, --decode decode facility and level to readable string Supported log facilities: kern - kernel messages user - random user-level messages mail - mail system daemon - system daemons auth - security/authorisation messages syslog - messages generated internally by syslogd lpr - line printer subsystem news - network news subsystem Supported log levels (priorities): emerg - system is unusable alert - action must be taken immediately crit - critical conditions err - error conditions warn - warning conditions notice - normal but significant condition info - informational debug - debug-level messages

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

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

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

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

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

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

  • /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
  • /var/log/auth.log или /var/log/secure - информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
  • /var/log/dmesg - драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.
Поддерживаемые уровни журналирования (приоритеты): emerg - система неиспользуемая alert - действие должно быть произведено немедленно crit - условия критичности err - условия ошибок warn - условия предупреждений notice - обычные, но значимые условия info - информационный debug - отладочные сообщения (5:520)$ dmesg -l err usb 1-1.1: 2:1: cannot get freq at ep 0x1 usb 1-1.1: 1:1: cannot get freq at ep 0x81 usb 1-1.1: 1:1: cannot get freq at ep 0x81
  • /var/log/alternatives.log - Вывод программы update-alternatives , в котором находятся символические ссылки на команды или библиотеки по умолчанию.
  • /var/log/anaconda.log - Записи, зарегистрированные во время установки системы.
  • /var/log/audit - Записи, созданные службой аудита auditd .
  • /var/log/boot.log - Информация, которая пишется при загрузке операционной системы.
  • /var/log/cron - Отчет службы crond об исполняемых командах и сообщения от самих команд.
  • /var/log/cups - Все, что связано с печатью и принтерами.
  • /var/log/faillog - Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog .
  • var/log/kern.log - Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
  • /var/log/maillog/ или /var/log/mail.log - Журнал почтового сервера, используемого на ОС.
  • /var/log/pm-powersave.log - Сообщения службы экономии заряда батареи.
  • /var/log/samba/ - Логи файлового сервера Samba , который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
  • /var/log/spooler - Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
  • /var/log/Xorg.0.log - Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

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

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

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

  • /var/log/lastlog - Последняя сессия пользователей. Прочитать можно командой last .
  • /var/log/tallylog - Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
  • /var/log/btmp - Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
  • /var/log/utmp - Список входов пользователей в систему на данный момент.
  • /var/log/wtmp - Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .
(5:535)$ sudo utmpdump /var/log/wtmp [Вт авг 11 16:50:07 2015] [~~ ] [Вт авг 11 16:50:08 2015] [~~ ] [Вт авг 11 16:50:57 2015] [Вт авг 11 16:50:57 2015] [~~ ] [Вт авг 11 16:50:57 2015]

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

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

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

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

  • ~/.xsession-errors - Вывод stderr графических приложений X11.
Initializing "kcm_input" : "kcminit_mouse" Initializing "kcm_access" : "kcminit_access" Initializing "kcm_kgamma" : "kcminit_kgamma" QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0 kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing. QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0 Qt: Session management error: networkIdsList argument is NULL
  • ~/.xfce4-session.verbose-log - Сообщения рабочего стола XFCE4.

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

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


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




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


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

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

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

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


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

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


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

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


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

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

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

Все лог файлы linux распологаются в папке:
/var/log

log-файлы линукс:
messages Содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы.
dmesg Содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны.
auth.log Содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.
boot.log Содержит информацию, которая регистрируется при загрузке системы.
daemon.log Включает сообщения от различных фоновых демонов
kern.log Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.
lastlog Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.
mail.log журналы сервера электронной почты, запущенного в системе.
user.log Информация из всех журналов на уровне пользователей.
Xorg.x.log Лог сообщений Х сервера.
btmp Содержит информацию о неудачных попытках входа.
cups Все сообщения, связанные с печатью и принтерами.
cron Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.
secure Содержит информацию, относящуюся к аутентификации и авторизации.
wtmp Содержит журнал входа пользователей в систему. Используйте команду wtmp, чтобы отобразить содержимое этого файла.
faillog Содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.
mysqld.log Содержит файлы логов сервера баз данных MySQL.

Посмотреть логи linux можно с помощью нескольких консольных программ. Ниже разберем несколько примеров:

1. Вывод и пролистываение текста с помощью less:
less /var/log/messages

2. Просмотр логов в реальном времени:
tail -f /var/log/messages

3. Открываем файл с помощью cat:
cat /var/log/dmesg

4. Выводим первые 10 строк из файла:
head /var/log/dmesg

5. Выводим последние 10 строк из файла:
tail /var/log/dmesg

6. Выводим определенное количество строк:
head -n3 /var/log/dmesg
где, -n3 — количество строк которое нужно показать.

7. Выводим только ошибки:
grep -i error /var/log/messages

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