В процессе своей работы система отслеживает и сохраняет в специальные файлы некоторые события, которые она считает важными или просто нужными для использования в целях исправления и отладки ошибок, сбойных конфигураций и т. д. Файлы, в которых хранятся эти события называются файлами журналов или файлами регистрации. Нередко файлы регистрации занимают слишком много дискового пространства, что может свидетельствовать как о неисправности системы, ошибках конфигураций, так и о просто неправильной настройке демонов регистрации событий, которые отслеживают и собирают всё подряд. Таким образом работа с системой регистрации событий - важная составляющая в работе любого системного администратора, от которой всецело зависит качество обслуживания систем и как следствие - их надёжность и долговечность.
Как устроена система регистрации событий?
Опытные системные администраторы знают, что просматривать и анализировать журналы (файлы) регистраций необходимо регулярно и с особой тщательностью. Информация, содержащаяся в журналах очень часто помогает быстро решить возникающие неполадки или выявить скрытые проблемы в конфигурации системы. Для отслеживания событий системой, проверки журналов, учёта, хранения, архивирования и удаления информации из этих журналов должен быть разработан и утверждён специальный регламент для организации, эксплуатирующей и/или обслуживающей системы, серверы и сети.
Основным инструментом регистрации событий в UNIX и Linu до сих пор остаётся демон syslogd системы Syslog. Но следует иметь в виду также и то, что на протяжении длительного времени из-за многообразия всевозможных ответвлений UNIX и версий Linux множество программных пакетов, служебных скриптов, сетевых демонов используют свои собственные журналы, порой отличающимся экзотическим форматом.
В общем случае системой Syslog (и другими специализированными программами) производится перехват отслеживаемого события и регистрация его в файле регистрации. Само регистрируемое событие представляет собой строку текста, содержащую данные о дате/времени, типе, степени важности события. Также в этот набор могут быть, в зависимости от ситуации, включены и другие данные. Сама строка регистрируемого события для выделения указанных компонентов разбивается символами-разделителями: пробелы, табуляции, а также знаками пунктуации.
Журналы регистрации легко просматривать, поскольку они являются обычными текстовыми файлами. Для эффективной работы с журналами используются самые стандартные инструменты из базовой поставки любого дистрибутива - команды и . Если нужно «ворошить» очень большие и сложные по формату журналы, то можно (и даже нужно) вместо утилиты grep использовать другой, гораздо более производительный и гибкий в подобных задачах инструмент - утилиту . Язык обработки текста Perl также очень хорошо подходит для этого.
Типичная запись системного журнала системы Syslog обычно выглядит следующим образом:
Dec 18 15:12:42 backup.main.superhosting.ru sbatchd: sbatchd/main: ls_info() failed: LIM is down; try later; trying ... Dec 18 15:14:28 system.main.superhosting.ru pop-proxy: Connection from 186.115.198.84 Dec 18 15:14:30 control.main.superhosting.ru pingem : office.main.superhosting.ru has not answered 42 times Dec 18 15:15:05 service.main.superhosting.ru vmunix: Multiple softerrors: Seen 100Corrected Softerrors from SIMM J0201 Dec 18 15:15:16 backup.main.superhosting.ru PAM_unix: (sshd) session closed "for user trent
В данном случае можно видеть, что в одном из журналов Syslog собраны события из нескольких источников: программы sbathd, pingem, pop-proxy. Также можно видеть, что события регистрируются для нескольких хостов, взаимодействующих с данной системой: backup, system, office и service.
log файлы и их расположение в Linux
Как уже отмечалось, в системах UNIX и Linux нет чётких соглашений о том, где и как должны храниться журналы регистрации. Они могут быть разбросаны хоть по всей файловой системе, поэтому для каждого администратора важно сразу разобраться, где и для каких пакетов и демонов находятся соответствующие файлы журналов. Но несмотря на отсутствие чётких формальных регламентов относительно мест хранения журналов, всё же существует традиционно сложившееся правило, что эти файлы должны находиться в каталогах /var/log, /var/log/syslog, а также в /var/adm.
Как правило, доступ для чтения файлов в указанных каталогах предоставляется только суперпользователю, однако нет ничего страшного, если для часто просматриваемых журналов, в которых также нет важной системной информации настроить более «демократический» режим доступа. Обычно к такому варианту также прибегают для удобства и экономии времени, когда нужно часто и регулярно изучать некоторые журналы, например для веб-сервера Apache, которые обычно находятся в /var/log/apache2 или /var/log/httpd.
Стоит также помнить и о том, что бывают случаи, когда (особенно на сбойных конфигурациях) общий объём файлов журналов резко увеличивается, при этом велик риск «уложить» систему. Для удобства контроля за свободным пространством на устройствах хранения, а также для надёжности каталог /var часто выносят в отдельную файловую систему на отдельном разделе.
Некоторые специальные файлы журналов
В следующей таблице приводятся сведения о некоторых журнальных файлах, информация из которых очень полезна для системного администрирования:
| Файл | Программа | Место | Частота | Системы | Назначение |
| acpid | acpid | Ф | 64к | RZ | События, связанные с системой питания |
| auth.log | sudo и прочие | S | М | U | Информация об авторизации |
| apache2/* | httpd или apache2 | Ф | Д | ZU | Журналы веб-сервера Apache |
| apt* | APT | Ф | М | U | Установщики пакетов |
| boot.log | Сценарии запуска | Ф | М | R | Логи сценариев запуска |
| boot.msg | Ядро | В | - | Z | Образ буфера сообщений ядра |
| cron, | cron | S | Н | RAH | Логи и сведения о работе демона cron |
| cups/* | CUPS | Ф | Н | ZRU | Сообщения, связанные с системой печати |
| daemon.log | Разное | S | Н | U | Сообщения средств демонов |
| debug | Разное | S | Д | U | Сообщения для отладки |
| dmesg | Ядро | В | - | RU | Образ буфера сообщений ядра |
| dpkg.log | dpkg | Ф | М | U | Установщики пакетов |
| faillog | login | Н | Н | RZU | Информация о неудачных попытках авторизации |
| apache2/* | Httpd или apache2 | Ф | Д | R | Журналы веб-сервера Apache для каталога /etc |
| kern.log | login | В | - | RZ | Все сообщения средств ядра |
| lastlog | login | В | - | RZ | Время последней регистрации в системе каждого пользователя (этот файл бинарный) |
| mail* | Программы электронной почты | S | Н | Все | Сообщения средств электронной |
| messages | Разное | S | Н | RZUS | |
| rpmpkgs | cron.daily | В | Д | R | Список установленных RPM-пакетов |
| samba/* | smbd и прочие | Ф | Н | - | Сведения о работе сервера Samba |
| secure | sshd и прочие | S | М | R | Конфиденциальные авторизационные сообщения |
| sulog | su | Ф | - | SAH | Сведения об удачных и неудачных попыток использования команды su |
| syslog* | Разное | S | H | SUH | Основной системный журнальный файл |
| warn | wpar | S | H | Z | События уровня системных предупреждений/ошибок |
| wpars/* | wpar | Ф | - | А | Сведения о событиях загрузочных разделов |
| wtmp | login | В | M | Все | Сообщения о регистрации в системе (бинарный файл) |
| xen/* | Xen | Ф | 1m | RZU | Информация от монитора виртуальных машин Xen |
| Xorg.n.log | Xorg | Ф | Н | RS | Сообщения об ошибках сервера X Windows |
| yum.log | yum | Ф | М | R | Журнал управления пакетом |
Для данной таблицы действуют следующие обозначения: S - Syslog, В - встроенное имя, Ф - конфигурационный файл, Д - ежедневно, Н - еженедельно, М - ежемесячно, NN - размер в килобайтах или мегабайтах, Z - SUSE, R - Red Hat и CentOS, S - Solaris, H - HP-UX, A - AIX. В столбце «Частота» указывается частота, с которой удаляется устаревшая информация, связанная со временем или с объёмом файла. В столбце «Программа» указывается программа, создающая файл.
Следует отметить также, что большая часть сообщений для представленных в таблице файлов направляется в систему Syslog. Уровень критичности и программа, создающая файл задаются в конфигурационном файле /etc/initlog.conf. - так работает система Syslog. Файл faillog является двоичным, и поэтому может быть прочтён утилитой failog.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .
П еред тем, как начать с этого руководства рекомендуется, чтобы вы вошли на свой Linux и следовать этому руководству, глядя непосредственно на файлы, так как это лучший способ узнать и запомнить тему.
Узнайте о файлах журналов, когда ваша система работает гладко, как это понимание лог-файлов поможет вам успешно диагностировать и устранить любые проблемы, которые могут возникнуть в дальнейшем.
И, наконец, ‘файлы журнала Linux ‘ является довольно обширной темой, и она вряд ли будет полностью покрыта в одной статье. Эта статья, вероятно, может служить только в качестве общего руководства. Каждое приложение, установленное в системе имеет свой собственный механизм протоколирования всякий раз, когда вам нужно конкретную информацию по приложению, то документация приложения является лучшим местом, где искать его.
Общие файлы журнала
В качестве общего стандарта в почти каждой системе Linux, файлы журналов находятся в каталоге /var/log . Любые другие приложения, которые вы можете позже установить на вашей системе, вероятно, бросят свои файлы журнала здесь. После входа в вашу систему, наберите команду
Ls -l /var/log
Чтобы просмотреть содержимое этого каталога.
/var/log/messages
– Большая часть общих системных сообщений регистрируются здесь, включая сообщения во время запуска системы.
/var/log/cron
– Сообщения демона cron регистрируются здесь. Создается и останавливаются задачи, а также сообщения об ошибках.
/var/log/maillog
или /var/log/mail.log
– Регистрация информации почтового сервера, запущенного на сервере.
/var/log/wtmp
– Содержит историю всех входов и выходов.
/var/log/btmp
– Записи неудачных попыток входа в систему.
/var/run/utmp
– Логирование настоящего входа в состояние каждого пользователя.
/var/log/dmesg
– Содержит очень важные сообщения о ядре кольцевого буфера. В человеческом понимании это означает, что, когда ядро раскручивается он записывает всю информацию здесь. Команда dmesg
может быть использована для просмотра сообщений этого файла.
/var/log/secure
– Сообщения, связанные с безопасностью будут храниться здесь. Это включает в себя сообщения от SSH – демона, неудачный ввод пароля, несуществующих пользователей и т.д.
/var/log/mariadb
– Если MariaDB установлена в системе, то это место, где она будет бросать журналы по умолчанию
/var/log/mysql
– Если база данных устанавливается, то это директория записи данных по умолчанию.
Просмотр и управление файлами журналов
Первичная регистрация Linux демона процесс rsyslogd и его конфигурация находится в /etc/rsyslog.conf .
Для всех файлов журналов с открытым текстом, журналы можно просмотреть с помощью команды cat . Однако, если файл журнала очень большой, то вы можете захотеть использовать команду tail , которая может показать только последнюю часть журнала.
Для просмотра последних 500 записей файла введите следующую команду:
Tail -n 500 /var/log/messages
Для мониторинга журналов в режиме реального времени tail -f также очень полезная команда, которая будет отслеживать сообщения, как они вошли. Это особенно полезно при поиске и устранении потоков почты и ошибки доставки почты.
Tail -f /var/log/maillog
Некоторые журналы Linux, как бинарные файлы, которые должны быть разобраны другим приложением, специально адаптированный для просмотра этих журналов. Эти журналы сохраняются в /var/log/wtmp /var/log/btmp и /var/run/utmp .
Для просмотра содержимого /var/log/wtmp используется: last
Для просмотра содержимого /var/log/btmp используется: lastb
Для просмотра содержимого /var/run/utmp используется: who
Cpanel файлы конкретных журналов
Файлы журнала Apache:
/usr/local/apache/logs/ – Общие журналы .
/usr/local/apache/domlogs/ – Журналы конкретного домена.
файлы журнала Exim:
/var/log/exim_mainlog
/var/log/exim_rejectlog
Файлы журнала Cpanel:
/usr/local/cpanel/logs/ – Все связанные с Cpanel сообщений в этом месте.
Файлы конкретных журналов DirectAdmin
Файлы журнала DirectAdmin
/var/log/directadmin/ – DirectAdmin связанные журналы.
Файлы журналов
/var/log/httpd/ – Веб-сервер Apache вошли в стандартный каталог.
/var/log/httpd/domains/ – Для всех остальных доменов журналы находятся в этом подкаталоге.
Файлы журнала
/var/log/proftpd/ – Если используется ProFTPd.
/var/log/pureftpd.log – Если используется PureFTPd.
Файлы журналов Exim
/var/log/exim/ – Журналы агента пересылки почты Exim в этой директории.
Файлы журналов
/var/lib/mysql/server.hostname.com.err – Это каталог, ведение журнала на наличие ошибок, связанных с .
Файлы журналов
/var/log/yum.log – Логирование менеджера пакетов Yum.
/var/log/httpd – В системах, основанных на / RedHat CentOS это где веб-сервер Apache будет хранить журналы по умолчанию.
Файлы журналов
/var/log/apache2/ – На системах Ubuntu журналы веб-сервера Apache хранятся в этом каталоге.
/var/log/apt/ – Журналы из управления пакетами в Ubuntu.
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, --fileGetting 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
Лог файл (файл журнала), как вы наверное догадались, сохраняет хронологию событий для операционной системы Linux, её приложений и служб.
Файлы хранятся в виде обычного текста, чтобы их можно было легко читать. В нашей статье мы расскажем, где найти лог файлы, приведем в пример несколько основных файлов журнала и объясним, как их читать.
Где находятся лог файлы в Linux
Файлы журналов Linux обычно хранятся в папке /var / logs.
В папке хранится большое количество файлов, из которых вы можете получить информацию для каждого приложения.
Например, когда команда ls выполняется к примеру в папке /var/logs, вот несколько доступных журналов:
- kern.log
- auth.log
- bootstrap.log
- alternatives.log
- samba
- lightdm
Последние три из этого списке являются папками, но у них есть также есть файлы журнала.
Поскольку лог файлы находятся в текстовом формате, их можно прочитать, введя следующую команду:
Приведенная выше команда открывает файл журнала в редакторе nano. Если лог файл имеет небольшой размер, то нет ничего лучше, чем открыть файл журнала в редакторе, но если файл журнала большой, то вас, вероятно, интересует только конец журнала.
Можно указать, сколько строк должно отображаться с помощью параметра -n следующим образом:
Если же вы хотите увидеть начало файла, вы можете использовать команду head.
Основные системные журналы
Следующие лог файлы являются основными в Linux.
- Журнал авторизации
- Журнал демонов
- Журнал отладки
- Журнал ядра
- Системный журнал
Журнал демонов (daemon.log) отслеживает службы, работающие в фоновом режиме и выполняющие важные задачи. Демоны, как правило, не выводятся на экране.
Журнал отладки предоставляет вывод отладок для приложений.
Журнал ядра содержит подробные сведения о ядре Linux.
Системный журнал содержит большую часть информации о вашей системе, и если у какого-то приложения нет своего собственного журнала, записи, вероятно, будут в этом лог файле.
Анализ содержимого файла журнала
Изображение выше показывает содержание последних 50 файлов в файле системного журнала (syslog).
Каждая строка журнала содержит следующие данные:
- Имя хоста
- Служба/Приложение
- Сообщение
Пример одной из строк в файле syslog:
jan 20 12:28:56 gary-virtualbox systemd: starting cups scheduler
Ротация логов
Файлы журнала периодически меняются, чтобы они не становились слишком большими.
Утилита log rotate отвечает за ротацию файлов журнала. Вы можете определить, что журнал был заменен, потому что его название будет содержать число, такое как auth.log.1, auth.log.2.
Можно изменить частоту замены журнала, отредактировав файл /etc/logrotate.conf.
Ниже показан пример записей из файла logrotate.conf:
#rotate log files
weekly#keep 4 weeks worth of log files
create new log files after rotating
Как вы можете видеть, эти файлы журналов меняются каждую неделю, и одновременно могут хранятся лог файлы за четыре недели.
При замене файла журнала на его месте создается новый файл.
Каждое приложение может иметь свою собственную политику ротации. Это, определенно, полезно, потому что файл системного журнала будет расти быстрее, чем файл журнала cups.
Политики ротации хранятся в /etc/logrotate.d. У каждого приложения, для которого требуется собственная политика ротации, в папке с приложением будет храниться файл конфигурации.
Например, инструмент apt содержит файл в папке logrotate.d со следующим содержанием:
/var/log/apt/history.log {
rotate 12
monthly
compress
missingok
notifempty
}
В принципе, этот журнал говорит вам следующее. Журнал будет хранить лог файлы в течение 12 недель и будет меняться каждый месяц (по одному в месяц). Файл журнала будет сжат. Если в журнал не записываются сообщения (т.е. он пуст), это нормально. Журнал не будет заменяться на новый, если он пустой.
Чтобы изменить политику файла, замените его параметры на нужные вам, а затем выполните следующую команду:
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Так как это постоянный вопрос новых пользователей на Линукс-форумах, им посвящается этот пост.
Новичку на форуме Линукс.
// читается скороговоркой//
Помогите телепатам!
Сообщите про железо,
Расскажите о системе,
Не скрывая ничего.
В этом деле благородном
Да поможет вам дэмэседж
*
Вместе с эльэсписиаем
**
Не забудьте про унэйм
***
Не скрывайте ваши логи,
И конфиги, кстати, тоже,
А запостите на форум
Со скриншотами на пару.
И тогда уж стопудово
Аксакалы юниксвея
Вам помогут и подскажут,
Как систему починить.
----------------------
* имеется в виду dmesg
** вывод команды lspci
*** команда uname -a
Зачем нужны лог-файлы и почему они важны
Нормальные [?]
операционные системы ведут подробный протокол собственных действий, записывая всё происходящее в текстовые файлы, log-файлы, лог-файлы или логи
. Это обычные текстовые файлы, которые можно прочесть любым текстовым редактором (или средствами самой операционной системы), хотя многие логи доступны на чтение только пользователю root.
Главное:
по логам можно восстановить почти полную картину неполадки, попутно выяснив особенности вашего железа и степени его поддержки.
Вот как выглядят лог-файлы в Linux:
usbcore: registered new interface driver hiddevИз этого куска лога видно, что произошло два события:
input: Logitech USB Receiver as /class/input/input1
input: USB HID v1.11 Mouse on usb-0000:00:1d.0-1
input: Logitech USB Receiver as /class/input/input2
input,hiddev96: USB HID v1.11 Device on usb-0000:00:1d.0-1
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
usb 1-5: new high speed USB device using ehci_hcd and address 3
usb 1-5: configuration #1 chosen from 1 choice
scsi0: SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access ChipsBnk SD/MMCReader 4081 PQ: 0 ANSI: 2
sd 0:0:0:0: 499712 512-byte hardware sectors (256 MB)
sd 0:0:0:0: Write Protect is off
sd 0:0:0:0: Mode Sense: 0b 00 00 08
sd 0:0:0:0: Assuming drive cache: write through
sda: sda1 sda2
sd 0:0:0:0: Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
- подключилась мышь (выделено фиолетовым): input: USB HID v1.11 Mouse on usb-0000:00:1d.0-1 и скорее всего эта мышь беспроводная (об этом говорит USB Receiver )
- подключили USB-накопитель (выделено зелёным):
usb 1-5: new high speed USB device using ehci_hcd and address 3, который опознан как USB-диск
scsi0: SCSI emulation for USB Mass Storage devices ёмкостью 256Мб
sd 0:0:0:0: 499712 512-byte hardware sectors (256 MB) и содержащий две партиции (два раздела с данными)
sda: sda1 sda2
.
Где хранятся лог-файлы в Linux
Все лог-файлы должны лежать в одном каталоге, который находится тут:
В общем, довольно логично. Но заходить туда не обязательно: вспоминаем, что консоль - наш друг и мощное оружие в умелых руках. Для того, чтобы быстро получить логи и прикрепить их к посланию на форум / опубликованию / пересылке по почте делаем так:
- Из консоли:
- в графическом режиме - в меню программ она может называться xterm, terminal, konsole, bash.
- в консольном режиме - если видите перед собой чёрный экран со словами типа penta4@penta4rce:~$ ничего пока делать не надо - вы и так в консоли:-)
- Далее пишем:
- dmesg > dmesg.txt
- lspci -v > lspci.txt
- cp /var/log/X.org.0.log ~/
- Далее видим в своём домашнем каталоге файлы dmesg.txt и lspci.txt и X.org.0.log
Для более подробного изучения неполадки и выяснения особенностей работы аппаратуры можно использовать приёмы работы, замечательно описанные
