Просмотр «журнала ошибок» в windows 10

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

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

Шпаргалка по journalctl

Вывод journalctl представляет из себя цельный список всех сохраненных сообщений. Если вы запустите команду journalctl без параметров, то получите самые первые сообщения, которые были сохранены. В моем случае это данные за 13 января:

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

янв 13 20:55:55 sergiy-pc kernel: Linux version 4.15.0-43-generic

• янв 13 20:55:55 — дата и время события;
• sergiy-pc — хост, на котором произошло событие;
• kernel — источник события, обычно это программа или сервис. В данном случае ядро;
• Linux version 4.15.0-43-generic — само сообщение.

Давайте перейдем к примерам фильтрации и перемещения.

1. Просмотр логов сервисов

Самый частый случай использования journalctl — это когда вы пытаетесь запустить какой-либо сервис с помощью systemd, он не запускается и systemd выдает вам такое сообщение подобного содержания: Failed to start service use journalctl -xe for details. Система сама предлагает вам какую команду надо выполнить:

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

Чтобы отфильтровать сообщения только от определенного сервиса можно использовать опцию -u. Например:

2. Просмотр логов в режиме tail

С помощью опции -f можно указать утилите, что необходимо выводить новые сообщения в реальном времени:

В этом режиме less не поддерживается, поэтому для выхода нажмите сочетание клавиш Ctrl+C.

3. Просмотр логов загрузки

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

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

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

4. Фильтрация по дате

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

Опция —until помогает указать по какую дату вы хотите получить информацию:

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

Кроме даты в формате YYYY-MM-DD в этих опциях можно использовать такие слова, как yesterday, today, и tomorrow. Также допустимы конструкции 1 day ago (один день назад) или 3 hours ago (три часа назад). Ещё можно использовать знаки + и -. Например -1h30min будет означать полтора часа назад.

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

6. Настройка формата вывода

По умолчанию journalctl выводит информацию с помощью утилиты less, в которой вы можете её удобно листать и просматривать. Но формат вывода можно изменить:

• short — используется по умолчанию;
• verbose — также, как и short, только выводится намного больше информации;
• json — вывод в формате json, одна строка лога в одной строке вывода;
• json-pretty — форматированный вывод json для более удобного восприятия;
• cat — отображать только сообщения, без метаданных.

Чтобы указать нужный формат используйте опцию -o. Например:

Или:

7. Очистка логов

Сначала нужно посмотреть сколько ваши логи занимают на диске. Для этого используйте такую команду:

Чтобы уменьшить размер лога можно использовать опцию —vacuum-size. Например, если вы хотите, чтобы ваши файлы журналов занимали на диске не более 2 Гб, выполните команду:

Теперь старые логи будут удалены, пока общий объем хранилища не будет составлять 2 гигабайта. Также можно удалять логи по времени. Для этого используется опция —vacuum-time. Например, оставим только логи за последний год:

Journalctl: просмотр логов

-- Logs begin at Wed 2015-07-29 17:12:48 MSK, end at Thu 2015-07-30 11:24:15 MSK. --
Jul 29 17:12:48 host-10-13-37-10 systemd-journal: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 systemd-journal: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuset
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpu
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuacct
Jul 29 17:12:48 host-10-13-37-10 kernel: Linux version 3.16.0-4-amd64 ([email protected]) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Jul 29 17:12:48 host-10-13-37-10 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=b67ea972-1877-4c5b-a328-29fc0d6c7bc4 ro console=tty1 console=ttyS0 video=640x480 consoleblank=0 panic=15 c

sudo

sudo — это утилита, позволяющая выполнить команды с правами суперпользователя root. Перед именами команд, которые работают с файловой системой вне домашнего каталога, а так же для остановки root-процессов, нужно писать sudo. sudo используется для консольных приложений, в старых версиях убунту была утилита gksu которая позволяла запускать из под рута графические приложения (показывала окно ввода пароля перед запуском). Из Ubuntu 18.04 убрали ее, вместо нее предлагается использовать что-то типа .

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

Либо можно использовать или .

Какие инструменты нужны для исправления системных ошибок

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

Желательно иметь в наличии и уметь пользоваться такими инструментами:

1. Диск с Windows 7, 8 или 10, который понадобится в крайнем случае, при необходимости переустановить систему полностью или некоторые потерянные данные.

2. Загрузочный диск с Windows РЕ. В виртуальной среде Windows намного проще исправлять многие системные ошибки и чтобы открыть ее и работать, необходим реаниматор, который вы можете записать на внешний цифровой носитель. Например, на флешку. Мы рекомендуем выбрать реаниматор Alkid Live CD/DVD/USB – это оптимальная сборка и его без труда можно скачать в интернете бесплатно.

3. Флешка или диск, при условии наличия дисковода на вашем ПК, с антивирусным сканером.

Основы просмотра журнала

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

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

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

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

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

Все журналы отображаются с использованием этой новой информации.

Если вы хотите вывести временные метки в формате UTC, вы можете использовать флаг :

Команда lsof

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

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

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

Горячие клавиши journalctl

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

• Стрелка вниз, Enter, e или j — переместиться вниз на одну строку;
• Стрелка вверх, y или k — переместиться на одну строку вверх;
• Пробел — переместиться на одну страницу вниз;
• b — переместиться на одну страницу вверх;
• Стрелка вправо, стрелка влево — горизонтальна прокрутка;
• g — перейти на первую строку;
• G — перейти на последнюю строку;
• p — перейти на позицию нужного процента сообщений. Например, 50p перенесет курсор на середину вывода;
• — поиск по журналу;
• n — найти следующее вхождение;
• N — предыдущее вхождение;
• q — выйти.

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

Boot entries

If you want to list out only the boot process and how services fared during the booting of the system, issue the command:

journalctl -b

This will list entries of the boot journal for the most recent boot of the system (Figure C).

Figure C

Journal entries for the most recent boot.

Say you want to see the journal output of the previous boot. If the current boot is 0, the previous boot would be -1. That command would be:

journalctl -b -1

The boot prior to that would be:

journalctl -b -2

Continue on like that, until you find the boot journal you’re looking for. That is a very handy way to compare your current boot (one that might have issues) to a previous boot instance where certain services failed to start.

If you’re not sure how many boots the system has experienced, issue the command:

journalctl --list-boots

You should see a list of boots which includes all of the information you need to know which boot journal you should view (Figure D).

Figure D

The journalctl boot listing.

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

Пользователь ПК может самостоятельно предотвратить многие сбои системы, для этого ему время от времени нужно просматривать раздел журнала «Приложения».

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

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

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

Log namespaces

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

Journald не требует себе никаких специальных привилегий и может быть запущен даже от обычного пользователя (если пользователю разрешено писать в каталог с журналами, указанный в конфиге). Он поддерживает несколько инстансов с разными конфигами, причём «инстанс» указывается очень просто — имя инстанса передаётся первым аргументом командной строки. Например, вот так:

Руками этого делать чаще всего не нужно, потому что:

1) В опциях systemd-unit’а можно указать

2) после чего systemd попытается писать в сокеты (устройства и т.д.) в

3) Что приведёт к активации socket-юнита

4) Что (через систему зависимостей) приведёт к активации

5) Что приведёт к запуску (в виде сервиса)

6) Который прочитает файл (если найдёт).

7) И пойдёт писать всё, что пишут в этот в журнал в

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

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

Фактически, написанного (плюс чуть-чуть ) достаточно для того, чтобы начать его использовать. Остаются вопросы эргономики, эксплутации и производительности.

Команда id

Команда id используется для получения информации по текущему пользователю. В следующем примере, я попытался установить анализатор сетевого трафика Wireshark, на что система отреагировала сообщением, что я не могу выполнить данную команду, т.к. не имею прав суперпользователя (root)

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

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

Настройка rsyslogd

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

Объект Приоритет Назначение 

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

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

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

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

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

Нет необходимости учить наизусть названия rsyslogd  объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.
Упражнение 2. Изменение правил в rsyslog.confyum install -y httpd

ErrorLog    syslog:local1

systemctl restart httpd

systemctl restart httpdecho «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.confsystemctl restart rsyslogdtail -f /var/log/messages-debuglogger -p daemon.debug «Daemon Debug Message»

Examples¶

Without arguments, all collected logs are shown
unfiltered:

journalctl

With one match specified, all entries with a field matching
the expression are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service
journalctl _SYSTEMD_CGROUP=/user.slice/user-42.slice/session-c1.scope

If two different fields are matched, only entries matching
both expressions at the same time are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097

If two matches refer to the same field, all entries matching
either expression are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

If the separator «» is used, two
expressions may be combined in a logical OR. The following will
show all messages from the Avahi service process with the PID
28097 plus all messages from the D-Bus service (from any of its
processes):

journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service

To show all fields emitted by a unit and about
the unit, option / should be used.
journalctl -u
expands to a complex filter similar to

_SYSTEMD_UNIT=.service
  + UNIT=.service _PID=1
  + OBJECT_SYSTEMD_UNIT=.service _UID=0
  + COREDUMP_UNIT=.service _UID=0 MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
    

(see
for an explanation of those patterns).

Show all logs generated by the D-Bus executable:

journalctl /usr/bin/dbus-daemon

Show all kernel logs from previous boot:

journalctl -k -b -1

Show a live log display from a system service
:

Приоритет сообщений в логах

Как rsyslog так и joirnald имеют одну общую штуку, касающуюся ведения логов. Это приоритет сообщений. Логи в системе генерируются в зависимости от типа события, а это событие, в свою очередь, имеет определенную степень критичности. Вот в зависимости от этой критичности, событию присваивается определенный приоритет. Знать типы приоритетов, совсем не лишнее, будет немного проще разбирать логи Linux.

Типы приоритетов:

emerg — наивысший приоритет, что-то сломалось, повод паниковать;

alert — тревога, стоит волноваться;

crit — критическое событие, нужно насторожиться;

err — ошибка, надо напрячься;

warning — внимание, нужно не терять бдительность;

notice — уведомление, можно не заморачиваться;

info — информационное сообщение, принять к сведению и забыть;

debug — отладочная информация, вообще пофиг;

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

Например:

Или в случае с journalctl:

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

Твой Pulse.

Терминал

В Ubuntu придется часто использовать терминал. Его можно вызвать сочетанием клавиш

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

Или если не работает первая:

Некоторые имеют подробный манул:

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

После запуска терминала мы по-умолчанию находимся в нашем домашнем каталоге. Он обозначается как ~. В терминале тильда в начале пути заменяется на . Файл сожержит команды, выполняемые интепретатором баша после запуска (например, при старте терминала). Имена исполняемых фалов, размещенных в каталогах или , доступны как команды.

— вставить символ EOF закрыть (закрывает терминал).

Если нужно выполнить одну единственную команду, то можно нажать Alt+F2 и ввести ее в поле.

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

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

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

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

Разберем детально каждую строку вышеприведенного фрагмента:

    — указывает команде не выводить ошибку, если лог-файл отсутствует.

    — если лог-файл пуст, то ротации не будет.

    — лог-файл необходимо сжать.

    — гарантирует, что лог-файл не превышает заданного размера, в противном случае производится его ротация.

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

    — создает экземпляр лог-файла, владельцем и группой которого является root.

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

Ошибки синего экрана – экрана смерти

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

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

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

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

Чтобы спасти систему от переустановки, нужно понять, а чем причина ошибки.

Проще всего это сделать, посмотрев на код сбоя, он указан после слова STOP на странице.

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

Команда netstat

Команда netstat отображает информацию о состоянии сети. Она показывает используемые сетевые порты и входящие соединения к ним. Однако стоит заметить, что команда не входит в базовую поставку Linux; утилита устанавливается вместе с пакетом net-tools.

Предположим, вы проводите локальные эксперименты со своей программой, принимающей входящие подключения от других программ. Может случиться так, что вы получите сообщение об ошибке типа «Необходимый вам порт (или адрес) уже занят». Применив команду с параметрами протокола, процесса и порта, мы увидим, что HTTP-сервер Apache уже использует 80 порт на нижеприведенном хосте:

Команда tar

Команда tar позволяет заархивировать несколько файлов в один архив.

В качестве примера, давайте создадим каталог ravesli_docs, и поместим в него три файла: a.txt, b.txt и c.txt:

Теперь с помощью команды создадим архив ravesli.tar, содержащий все файлы из каталога ravesli_docs:

Просмотрев с помощью команды содержимое текущего каталога можно заметить каталог ravesli_docs и вновь созданный нами архив ravesli.tar:

Для распаковки архива применяется команда :

Также вы можете задействовать gzip-сжатие для архива (для этого необходимо добавить параметр ):

Для распаковки сжатого архива применяется связка параметров и :

Journalctl: просмотр логов

-- Logs begin at Wed 2015-07-29 17:12:48 MSK, end at Thu 2015-07-30 11:24:15 MSK. --
Jul 29 17:12:48 host-10-13-37-10 systemd-journal: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 systemd-journal: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuset
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpu
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuacct
Jul 29 17:12:48 host-10-13-37-10 kernel: Linux version 3.16.0-4-amd64 ([email protected]) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Jul 29 17:12:48 host-10-13-37-10 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=b67ea972-1877-4c5b-a328-29fc0d6c7bc4 ro console=tty1 console=ttyS0 video=640x480 consoleblank=0 panic=15 c

Change the Log Output Format

Because the log records for systemd’s journals are structured, journalctl can show your logs in different formats. Here are a few of the formats available:

Format Name	Description
short	The default option, displays logs in the traditional syslog format.
verbose	Displays all information in the log record structure.
json	Displays logs in JSON format, with one log per line.
json-pretty	Displays logs in JSON format across multiple lines for better readability.
cat	Displays only the message from each log without any other metadata.

Pass the format name with the option to display your logs in that format. For example:

Anatomy of a Log Record

The following is an example of the structured data of a log record, as displayed by . For more information on this data structure, review
the man page for journalctl:

General Idea

One of the impetuses behind the journal is to centralize the management of logs regardless of where the messages are originating. Since much of the boot process and service management is handled by the process, it makes sense to standardize the way that logs are collected and accessed. The daemon collects data from all available sources and stores them in a binary format for easy and dynamic manipulation.

This gives us a number of significant advantages. By interacting with the data using a single utility, administrators are able to dynamically display log data according to their needs. This can be as simple as viewing the boot data from three boots ago, or combining the log entries sequentially from two related services to debug a communication issue.

Storing the log data in a binary format also means that the data can be displayed in arbitrary output formats depending on what you need at the moment. For instance, for daily log management you may be used to viewing the logs in the standard format, but if you decide to graph service interruptions later on, you can output each entry as a JSON object to make it consumable to your graphing service. Since the data is not written to disk in plain text, no conversion is needed when you need a different on-demand format.

The journal can either be used with an existing implementation, or it can replace the functionality, depending on your needs. While the journal will cover most administrator’s logging needs, it can also complement existing logging mechanisms. For instance, you may have a centralized server that you use to compile data from multiple servers, but you also may wish to interleave the logs from multiple services on a single system with the journal. You can do both of these by combining these technologies.

Основные сведения[править]

Ключи journalctlправить

Получить актуальные ключи команды:

journalctl --help

Чтение всех логов:

journalctl -b

Если был крах системы, можно ввести параметр -1 и посмотреть логи с предыдущего запуска системы (-2 логи сеанса за два сеанса до текущего и т.д.) :

journalctl -b -1

Показывать записи журнала с момента запуска системы с расшифровкой ошибок:

journalctl -xb

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

journalctl -f

Вывод лога в текстовый файлправить

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

'команда' > 'путь к текстовому файлу'

Пример:

journalctl -b > /home/user/debug.log

Фильтрация по дате и времениправить

Для фильтрации по дате и времени важны два ключа

—since — вывод от такого-то момента времени

—until — вывод до такого-то момента времени

в качестве значений для этих ключей могут использоваться:

— Формат YYYY-MM-DD HH:MM:SS

journalctl --since "2017-05-05 00:01" --until "2017-05-06 01:40"

— Слова «yesterday», «today», «tomorrow», «now»:

journalctl --since "yesterday" --until "2017-05-06 01:40"

— Удобочитаемые выражения вида:

journalctl --since "10 hours ago"
journalctl --since "1 minute ago"
journalctl --since "50 minute ago" --until "5 minute ago"

Примерыправить

Показать все сообщения за последние 20 минут:

journalctl --since "20 min ago"

Просмотреть все сообщения начиная с 20 июля 2015 года 17:15:

journalctl --since "2015-07-20 17:15:00"

Просмотреть все сообщения начиная со вчерашнего дня:

journalctl --since "yesterday"

Просмотреть все сообщения с 9:00 до настоящего времени:

journalctl --since "09:00" --until "now"

Просмотреть все сообщения с 9:00 до прошлого часа:

journalctl --since "10:00" --until "1 hour ago"

journalctl -af

Просмотр сообщений ядра :

journalctl -k

Все сообщение конкретной утилиты, например, systemd:

journalctl /usr/lib/systemd/systemd

Все сообщения конкретного процесса:

journalctl _PID=1

Все сообщения конкретного приложения или службы:

journalctl -u netcfg

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

journalctl _UID=33

Журналправить

strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i сообщение

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

из директории

journalctl -D /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd

из файла

journalctl --file /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal

Недавние событияправить

$ journalctl -n

По умолчанию на консоль выводится информация о последних 10 событиях. С опцией -n можно указать необходимое число событий:

$ journalctl -n 20

Логи Linux. journald

Рассказ про логи в Linux был бы не полным, если бы я не вспомнил про такую штуку как journald. Говоря линуксоидным языком — это служба сбора логов systemd-journald, которая является частью подсистемы инициализации и управления службами systemd. Другими словами это ещё одна служба сбора логов, самостоятельная и со своими особенностями. Основные особенности в том, что все логи хранятся в каталоге /var/log/journal/ и хранятся они в бинарном виде, потому просто посмотреть их как текстовый файл не получится. Для этого есть специальная утилита journalctl. Штука довольно замороченная, потому разберемся как с ней работать на конкретных примерах.

Здесь под цифрой 0 — текущая загрузка, -1 предыдущая и так далее. Теперь мы можем посмотреть логи касающейся конкретной загрузки. Так, если нам нужна позапрошлая загрузка, то так и указываем:

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

Чтобы увидеть сообщения ядра системы вводим:

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

Если нужно увидеть только несколько последних записей, то их количество можно задать параметром -n:

Ну и раз уж, уже вспомнили про systemd в целом, то наверное надо сказать и про systemd-analyze. Это такая штука которая собирает статистику загрузки системы.

Если ввести в терминале просто:

без каких-либо параметров, то мы увидим общее время загрузки системы. А если добавить параметр blame, то увидим сколько времени загружалась каждая служба, самые медленные процессы будут сверху.

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

Journal Filtering by Time

While having access to such a large collection of data is definitely useful, such a large amount of information can be difficult or impossible to inspect and process manually. Because of this, one of the most important features of is its filtering options.

Displaying Logs from the Current Boot

The most basic of these which you might use daily, is the flag. This will show you all of the journal entries that have been collected since the most recent reboot.

This will help you identify and manage information that is pertinent to your current environment.

In cases where you aren’t using this feature and are displaying more than one day of boots, you will see that has inserted a line that looks like this whenever the system went down:

This can be used to help you logically separate the information into boot sessions.

Past Boots

While you will commonly want to display the information from the current boot, there are certainly times when past boots would be helpful as well. The journal can save information from many previous boots, so can be made to display information easily.

Some distributions enable saving previous boot information by default, while others disable this feature. To enable persistent boot information, you can either create the directory to store the journal by typing:

Or you can edit the journal configuration file:

Under the section, set the option to “persistent” to enable persistent logging:

/etc/systemd/journald.conf

When saving previous boots is enabled on your server, provides some commands to help you work with boots as a unit of division. To see the boots that knows about, use the option with :

This will display a line for each boot. The first column is the offset for the boot that can be used to easily reference the boot with . If you need an absolute reference, the boot ID is in the second column. You can tell the time that the boot session refers to with the two time specifications listed towards the end.

To display information from these boots, you can use information from either the first or second column.

For instance, to see the journal from the previous boot, use the relative pointer with the flag:

You can also use the boot ID to call back the data from a boot:

Time Windows

While seeing log entries by boot is incredibly useful, often you may wish to request windows of time that do not align well with system boots. This may be especially true when dealing with long-running servers with significant uptime.

You can filter by arbitrary time limits using the and options, which restrict the entries displayed to those after or before the given time, respectively.

The time values can come in a variety of formats. For absolute time values, you should use the following format:

For instance, we can see all of the entries since January 10th, 2015 at 5:15 PM by typing:

If components of the above format are left off, some defaults will be applied. For instance, if the date is omitted, the current date will be assumed. If the time component is missing, “00:00:00” (midnight) will be substituted. The seconds field can be left off as well to default to “00”:

The journal also understands some relative values and named shortcuts. For instance, you can use the words “yesterday”, “today”, “tomorrow”, or “now”. You can do relative times by prepending “-” or “+” to a numbered value or using words like “ago” in a sentence construction.

To get the data from yesterday, you could type:

If you received reports of a service interruption starting at 9:00 AM and continuing until an hour ago, you could type:

As you can see, it’s relatively straightforward to define flexible windows of time to filter the entries you wish to see.