Какой командой вы посмотрите ошибки ядра произошедшие начиная со вчерашнего дня linux

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

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

dmesg - Утилита командной строки используется для печати и управления кольцевого буфера ядра в Linux и других Unix-подобных операционных систем. Это полезно для изучения загрузочных сообщений ядра и устранения проблем, связанных с оборудованием.

Использование dmesg команды

Синтаксис dmesg команды следующий:

При вызове без каких-либо параметров dmesgзаписывает все сообщения из кольцевого буфера ядра в стандартный вывод:

dmesg

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

dmesg: read kernel buffer failed: Operation not permitted

    Параметр ядра kernel.dmesg_restrict указывает, могут ли непривилегированные пользователи dmesg просматривать сообщения из буфера журнала ядра. Чтобы снять ограничения, установите его на ноль:

sudo sysctl -w kernel.dmesg_restrict=0

    Обычно выходные данные содержат много строк информации, так что только последняя часть выходных данных является видимой. Чтобы увидеть одну страницу за раз, перенаправьте вывод в утилиту пейджера, такую ​​как less или more:

dmesg --color=always | less

--color=always Используется для сохранения цветного вывода.

dmesg | grep -i usb


dmesg читает сообщения, сгенерированные ядром, из /proc/kmsg виртуального файла. Этот файл предоставляет интерфейс к кольцевому буферу ядра и может быть открыт только одним процессом. Если syslogв вашей системе запущен процесс, и вы пытаетесь прочитать файл с помощью cat, или less, команда зависнет.

syslog Демон отвалов сообщения ядра /var/log/dmesg, так что вы можете использовать этот файл журнала:

cat /var/log/dmesg

Форматирование dmesg вывода

Команда dmesgпредоставляет ряд опций, которые помогут вам отформатировать и отфильтровать вывод.

Одна из наиболее часто используемых опций dmesg— это -H ( --human), которая обеспечивает удобочитаемый вывод. Эта опция направляет вывод команды в пейджер:

dmesg -H

    Для печати удобочитаемых временных меток используйте опцию -T ( --ctime):

dmesg -T

[Mon Oct 14 14:38:04 2019] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready

   Формат --time-format <format> отметок времени также может быть установлен с помощью параметра, который может быть ctime, reltime, delta, notime или iso. Например, чтобы использовать дельта-формат, введите:

dmesg --time-format=delta

dmesg -H -T

    Чтобы просмотреть вывод dmesg команды в режиме реального времени, используйте параметр -w ( --follow):

dmesg --follow

Фильтрация dmesgвывода

Вы можете ограничить dmesg вывод данными объектами и уровнями.

Средство представляет процесс, который создал сообщение. dmesg поддерживает следующие возможности журнала:

• kern — сообщения ядра
• user — сообщения уровня пользователя
• mail — почтовая система
• daemon — системные демоны
• auth — сообщения безопасности / авторизации
• syslog — внутренние сообщения syslogd
• lpr — подсистема линейного принтера
• news — подсистема сетевых новостей

Опция -f( --facility <list>) позволяет ограничить вывод определенными объектами. Опция принимает одно или несколько разделенных запятыми объектов.

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

dmesg -f kern,daemon

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

• emerg — система неработоспособна
• alert — действие должно быть предпринято немедленно
• crit — критические условия
• err — условия ошибки
• warn — условия предупреждения
• notice — нормальное, но значимое состояние
• info — информационный
• debug — сообщения уровня отладки

Опция -l( --level <list>) ограничивает вывод определенными уровнями. Опция принимает один или несколько уровней, разделенных запятыми.

Следующая команда отображает только сообщения об ошибках и критические сообщения:

dmesg -l err,crit

Очистка кольцевого буфера

Опция -C( --clear) позволяет очистить кольцевой буфер:

sudo dmesg -C

    Только root или пользователи с привилегиями sudo могут очистить буфер.

Чтобы распечатать содержимое буфера перед очисткой, используйте параметр -c( --read-clear):

sudo dmesg -c

    Если вы хотите сохранить текущие dmesg журналы в файле перед его очисткой, перенаправьте вывод в файл:

dmesg > dmesg_messages

Вывод

Команда dmesgпозволяет вам просматривать и контролировать кольцевой буфер ядра. Это может быть очень полезно при устранении проблем с ядром или оборудованием.

Введите man dmesg в своем терминале информацию о всех доступных dmesg опциях.

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

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

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

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

Понимание ролей rsyslogd и journald

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

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

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

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

• Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
• Команда journalctl может использоваться для получения более подробной информации из журнала.
• Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status <unit>. Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

[root@server1 ~]# systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: failed (Result: exit-code) since Fri 2019-10-25 05:25:18
PDT; 2s ago
Process: 2893 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=0/SUCCESS)
Process: 2890 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
Main PID: 2890 (code=exited, status=1/FAILURE)
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address [::]:443
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address 0.0.0.0:443
Oct 25 05:25:18 server1.example.com httpd[2890]: no listening sockets
available, shutting down
Oct 25 05:25:18 server1.example.com httpd[2890]: AH00015: Unable to
open logs
Oct 25 05:25:18 server1.example.com systemd[1]: httpd.service: main
process exited, code=exited, status=1/FAILURE
Oct 25 05:25:18 server1.example.com systemd[1]: Failed to start The
Apache HTTP Server.
Oct 25 05:25:18 server1.example.com systemd[1]: Unit httpd.service
entered failed state.

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

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

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2

[root@kvm ~]# tail -n 20 /var/log/messages
Oct 31 22:05:56 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:06:09 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 15 (xid=0x278ccc34)
Oct 31 22:06:24 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 16 (xid=0x278ccc34)
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5185] dhcp4 (em1):request timed out
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5186] dhcp4 (em1):state changed unknown -> timeout
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):canceled DHCP transaction, DHCP client pid 24837
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):state changed timeout -> done
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5274] device (em1): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5284] device (em1): Activation: failed for connection 'Wired connection 1'
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5288] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm avahi-daemon[2499]: Withdrawing address record for fe80::6bbe:cb13:850c:d799 on em1.
Oct 31 22:06:41 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:10:01 kvm systemd: Created slice User Slice of root.
Oct 31 22:10:01 kvm systemd: Started Session 413 of user root.
Oct 31 22:10:01 kvm systemd: Removed slice User Slice of root.
Oct 31 22:10:08 kvm systemd-logind: New session 414 of user admin.
Oct 31 22:10:08 kvm systemd: Started Session 414 of user admin.
Oct 31 22:10:08 kvm dbus[2512]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Oct 31 22:10:08 kvm dbus[2512]: [system] Successfully activated service 'org.freedesktop.problems'
Oct 31 22:10:15 kvm su: (to root) admin on pts/11

Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

• Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
• Хост: хост, с которого отправлено сообщение. Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
• Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
• Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

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

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

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

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

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

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

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

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

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

Чтобы определить, какие типы сообщений должны логироваться, в строках rsyslog.conf могут использоваться разные уровни серьезности. Эти серьезности являются syslog-приоритетами. В таблице 3 представлен обзор доступных приоритетов в порядке возрастания.

Таблица 3

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

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

cron.=debug                     -/var/log/cron.debug

Нет необходимости учить наизусть названия rsyslogd  объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:

ErrorLog    syslog:local1

3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:

local1:error                    -/var/log/httpd-error.log

5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

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

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

ВНИМАНИЕ! Лог-файлы, которые были ротированы, нигде не хранятся; они просто исчезают. Если политика вашей компании требует от вас доступа к информации о событиях, которые произошли более 5 недель назад, вам следует принять меры. Вы можете либо создать резервную копию лог-файлов, либо настроить сервер логов, где logrotate хранит ротированные сообщения в течение значительно более длительного периода.

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

[root@kvm ~]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

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

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
[root@kvm ~]#

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

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

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

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

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

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4

Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5648] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5652] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5672] dhcp4 (em2): dhclient started with pid 23750
Nov 03 13:39:03 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:39:03 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 7 (xid=0x48a6ece5)
Nov 03 13:39:10 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 12 (xid=0x48a6ece5)
Nov 03 13:39:18 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:39:22 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 20 (xid=0x48a6ece5)
Nov 03 13:39:42 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 18 (xid=0x48a6ece5)
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5190] dhcp4 (em2): request timed out
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5191] dhcp4 (em2): state changed unknown -> timeout
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): canceled DHCP transaction, DHCP client pid 23750
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): state changed timeout -> done
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5284] device (em2): state change: ip-config -> failed (reason 'ip-config-
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5291] device (em2): Activation: failed for connection 'Wired connection 2
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5295] device (em2): state change: failed -> disconnected (reason 'none',
Nov 03 13:39:48 kvm avahi-daemon[2499]: Withdrawing address record for fe80::8cce:3bf7:7f8b:9335 on em2.
Nov 03 13:40:01 kvm systemd[1]: Created slice User Slice of root.
Nov 03 13:40:01 kvm systemd[1]: Started Session 867 of user root.
Nov 03 13:40:01 kvm CROND[23918]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Nov 03 13:40:01 kvm systemd[1]: Removed slice User Slice of root.
Nov 03 13:40:03 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.145 52:54:00:66:3d:c4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.145 52:54:00:66:3d:c4 server2
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6056] policy: auto-activating connection 'Wired connection 2' (17698f02-4
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6067] device (em2): Activation: starting connection 'Wired connection 2'
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6068] device (em2): state change: disconnected -> prepare (reason 'none',
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6073] device (em2): state change: prepare -> config (reason 'none', sys-i
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6339] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6347] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6396] dhcp4 (em2): dhclient started with pid 24344
Nov 03 13:44:48 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:44:48 kvm dhclient[24344]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 (xid=0x4c41d823)

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

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

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

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

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

Листинг 5

[root@kvm ~]# journalctl -o verbose
-- Logs begin at Tue 2019-10-29 13:15:14 +10, end at Sun 2019-11-03 14:04:03 +10. --
Tue 2019-10-29 13:15:14.573354 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=1;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d0a;t=596040660742a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 8.0M (max allowed 2.3G, trying to leave 3.5G free of 23.5G available → current limit 2.3G).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
    _PID=184
    _UID=0
    _GID=0
    _COMM=systemd-journal
    _EXE=/usr/lib/systemd/systemd-journald
    _CMDLINE=/usr/lib/systemd/systemd-journald
    _CAP_EFFECTIVE=5402800cf
    _SYSTEMD_CGROUP=/system.slice/systemd-journald.service
    _SYSTEMD_UNIT=systemd-journald.service
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
Tue 2019-10-29 13:15:14.573478 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=2;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d85;t=59604066074a6;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    MESSAGE=microcode: microcode updated early to revision 0x1d, date = 2018-05-11
Tue 2019-10-29 13:15:14.573513 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=3;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104da8;t=59604066074c9;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0

Сохранение журнала systemd

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

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Листинг 6

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.

Рекомендую прочитать «Логи в Linux часть 2. Расширенные функции логов».

Время на прочтение
6 мин

Количество просмотров 101K

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

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

Systemd

Systemd состоит из трех основных компонентов:

• systemd — менеджер системы и сервисов
• systemctl — утилита для просмотра и управление статусом сервисов
• systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd

Journald

Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.

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

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

Файл конфигурации journald

Файл конфигурации можно найти по следующему пути: /etc/systemd/journald.conf, он содержит различные настройки journald, я бы не рекомендовал изменять этот файл, если вы точно не уверены в том, что делаете.

Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).

Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.

Использование journalctl для просмотра и анализа логов

Основная команда для просмотра:

# journalctl

Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.

По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:

# journalctl --utc

Фильтрация событий по важности

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0

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

• 0: emergency (неработоспособность системы)
• 1: alerts (предупреждения, требующие немедленного вмешательства)
• 2: critical (критическое состояние)
• 3: errors (ошибки)
• 4: warning (предупреждения)
• 5: notice (уведомления)
• 6: info (информационные сообщения)
• 7: debug (отладочные сообщения)

Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.

Настройка хранения журналов

По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.

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

Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).

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

# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald

Просмотр журналов загрузки

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

# journalctl --list-boots

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

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

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

# journalctl -b 0

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

# journalctl -b -1

Просмотр журнала за определенный период времени

Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).

Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).

С определенной даты и времени:

# journalctl --since "2020-12-18 06:00:00"

С определенной даты и по определенное дату и время:

# journalctl --since "2020-12-17" --until "2020-12-18 10:00:00

Со вчерашнего дня:

# journalctl --since yesterday

С 9 утра и до момента, час назад:

# journalctl --since 09:00 --until "1 hour ago"

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

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

# journalctl -k

Просмотр журнала логов для определенного сервиса systemd или приложения

Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:

# journalctl -u NetworkManager.service

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

# systemctl list-units --type=service

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

# journalctl /usr/sbin/nginx --since today

Или указав конкретный PID:

# journalctl _PID=1

Дополнительные опции просмотра

Следить за появлением новых сообщений (аналог tail -f):

# journalctl -f

Открыть журнал «перемотав» его к последней записи:

# journalctl -e

Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:

journalctl --file /var/log/journal/e02689e50bc240f0bb545dd5940ac213/system.journal -f

По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.

Например:

SYSTEMD_LESS=FRXMK journalctl

Ограничение размера журнала

Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.

Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:

SystemMaxUse=50M

Удаление журналов

Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.

Удалить журналы, оставив только последние 100 Мб:

# journalctl --vacuum-size=100M

Удалить журналы, оставив журналы только за последние 7 дней:

# journalctl --vacuum-time=7d

Заключение

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

Журналы — это один из самых важных источников информации при возникновении любых ошибок в операционной системе Linux. Я это уже много раз говорил ранее и вот сказал ещё раз. Раньше в Linux для сохранения журналов сервисов использовался отдельный демон под названием syslogd. Но с приходом системы инициализации systemd большинство функций касающихся управления сервисами перешли под её управление. В том числе и управление логами.

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

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

journalctl опции

А теперь давайте разберем основные опции journalctl:

• —full, -l — отображать все доступные поля;
• —all, -a — отображать все поля в выводе full, даже если они содержат непечатаемые символы или слишком длинные;
• —pager-end, -e — отобразить только последние сообщения из журнала;
• —lines, -n — количество строк, которые нужно отображать на одном экране, по умолчанию 10;
• —no-tail — отображать все строки доступные строки;
• —reverse, -r — отображать новые события в начале списка;
• —output, -o — настраивает формат вывода лога;
• —output-fields — поля, которые нужно выводить;
• —catalog, -x — добавить к информации об ошибках пояснения, ссылки на документацию или форумы там, где это возможно;
• —quiet, -q — не показывать все информационные сообщения;
• —merge, -m — показывать сообщения из всех доступных журналов;
• —boot, -b — показать сообщения с момента определенной загрузки системы. По умолчанию используется последняя загрузка;
• —list-boots — показать список сохраненных загрузок системы;
• —dmesg, -k — показывает сообщения только от ядра. Аналог вызова команды dmesg;
• —identifier, -t — показать сообщения с выбранным идентификатором;
• —unit, -u — показать сообщения от выбранного сервиса;
• —user-unit — фильтровать сообщения от выбранной сессии;
• —priority, -p — фильтровать сообщения по их приоритету. Есть восемь уровней приоритета, от 0 до 7;
• —grep, -g — фильтрация по тексту сообщения;
• —cursor, -c — начать просмотр сообщений с указанного места;
• —since, -S, —until, -U — фильтрация по дате и времени;
• —field, -F — вывести все данные из выбранного поля;
• —fields, -N — вывести все доступные поля;
• —system — выводить только системные сообщения;
• —user — выводить только сообщения пользователя;
• —machine, -M — выводить сообщения от определенного контейнера;
• —header — выводить заголовки полей при выводе журнала;
• —disk-usage — вывести общий размер лог файлов на диске;
• —list-catalog — вывести все доступные подсказки для ошибок;
• —sync — синхронизировать все не сохраненные журналы с файловой системой;
• —flush — перенести все данные из каталога /run/log/journal в /var/log/journal;
• —rotate — запустить ротацию логов;
• —no-pager — выводить информацию из журнала без возможности листать страницы;
• -f — выводить новые сообщения в реальном времени, как в команде tail;
• —vacuum-time — очистить логи, давностью больше указанного периода;
• —vacuum-size — очистить логи, чтобы размер хранилища соответствовал указанному.

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

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

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

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

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

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

sudo journalctl

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

янв 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. Система сама предлагает вам какую команду надо выполнить:

sudo journalctl -xe

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

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

sudo journalctl -eu apache2.service

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

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

sudo journalctl -f

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

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

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

sudo journalctl -b

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

sudo journalctl -list-boots

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

sudo journalctl -b 37d5c906c9c6404682f029b2c34ec9dc

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

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

sudo journalctl --since "2019-01-20 15:10:10"

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

sudo journalctl -e --until "2019-01-20 15:05:50"

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

sudo journalctl --since "2019-01-20 15:10:10" --until "2019-01-20 15:05:50"

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

5. Журнал ядра

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

sudo journalctl -ek

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

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

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

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

sudo journalctl -o json-pretty

Или:

sudo journalctl -eo json-pretty

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

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

sudo journalctl --disk-usage

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

sudo journalctl --vacuum-size=2G

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

journalctl --vacuum-time=1years

Выводы

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

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

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

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

dmesg - Утилита командной строки используется для печати и управления кольцевого буфера ядра в Linux и других Unix-подобных операционных систем. Это полезно для изучения загрузочных сообщений ядра и устранения проблем, связанных с оборудованием.

Использование dmesg команды

Синтаксис dmesg команды следующий:

При вызове без каких-либо параметров dmesgзаписывает все сообщения из кольцевого буфера ядра в стандартный вывод:

dmesg

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

dmesg: read kernel buffer failed: Operation not permitted

    Параметр ядра kernel.dmesg_restrict указывает, могут ли непривилегированные пользователи dmesg просматривать сообщения из буфера журнала ядра. Чтобы снять ограничения, установите его на ноль:

sudo sysctl -w kernel.dmesg_restrict=0

    Обычно выходные данные содержат много строк информации, так что только последняя часть выходных данных является видимой. Чтобы увидеть одну страницу за раз, перенаправьте вывод в утилиту пейджера, такую ​​как less или more:

dmesg --color=always | less

--color=always Используется для сохранения цветного вывода.

dmesg | grep -i usb


dmesg читает сообщения, сгенерированные ядром, из /proc/kmsg виртуального файла. Этот файл предоставляет интерфейс к кольцевому буферу ядра и может быть открыт только одним процессом. Если syslogв вашей системе запущен процесс, и вы пытаетесь прочитать файл с помощью cat, или less, команда зависнет.

syslog Демон отвалов сообщения ядра /var/log/dmesg, так что вы можете использовать этот файл журнала:

cat /var/log/dmesg

Форматирование dmesg вывода

Команда dmesgпредоставляет ряд опций, которые помогут вам отформатировать и отфильтровать вывод.

Одна из наиболее часто используемых опций dmesg— это -H ( --human), которая обеспечивает удобочитаемый вывод. Эта опция направляет вывод команды в пейджер:

dmesg -H

    Для печати удобочитаемых временных меток используйте опцию -T ( --ctime):

dmesg -T

[Mon Oct 14 14:38:04 2019] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready

   Формат --time-format <format> отметок времени также может быть установлен с помощью параметра, который может быть ctime, reltime, delta, notime или iso. Например, чтобы использовать дельта-формат, введите:

dmesg --time-format=delta

dmesg -H -T

    Чтобы просмотреть вывод dmesg команды в режиме реального времени, используйте параметр -w ( --follow):

dmesg --follow

Фильтрация dmesgвывода

Вы можете ограничить dmesg вывод данными объектами и уровнями.

Средство представляет процесс, который создал сообщение. dmesg поддерживает следующие возможности журнала:

• kern — сообщения ядра
• user — сообщения уровня пользователя
• mail — почтовая система
• daemon — системные демоны
• auth — сообщения безопасности / авторизации
• syslog — внутренние сообщения syslogd
• lpr — подсистема линейного принтера
• news — подсистема сетевых новостей

Опция -f( --facility <list>) позволяет ограничить вывод определенными объектами. Опция принимает одно или несколько разделенных запятыми объектов.

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

dmesg -f kern,daemon

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

• emerg — система неработоспособна
• alert — действие должно быть предпринято немедленно
• crit — критические условия
• err — условия ошибки
• warn — условия предупреждения
• notice — нормальное, но значимое состояние
• info — информационный
• debug — сообщения уровня отладки

Опция -l( --level <list>) ограничивает вывод определенными уровнями. Опция принимает один или несколько уровней, разделенных запятыми.

Следующая команда отображает только сообщения об ошибках и критические сообщения:

dmesg -l err,crit

Очистка кольцевого буфера

Опция -C( --clear) позволяет очистить кольцевой буфер:

sudo dmesg -C

    Только root или пользователи с привилегиями sudo могут очистить буфер.

Чтобы распечатать содержимое буфера перед очисткой, используйте параметр -c( --read-clear):

sudo dmesg -c

    Если вы хотите сохранить текущие dmesg журналы в файле перед его очисткой, перенаправьте вывод в файл:

dmesg > dmesg_messages

Вывод

Команда dmesgпозволяет вам просматривать и контролировать кольцевой буфер ядра. Это может быть очень полезно при устранении проблем с ядром или оборудованием.

Введите man dmesg в своем терминале информацию о всех доступных dmesg опциях.

Увидеть ошибки, которые препятствуют загрузке системы, можно двумя способами:

1) на экране во время загрузки

2) с помощью команды journalctl

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

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

1.1 В меню загрузки нажмите е (или TAB). Откроется окно опций загрузки. Если в нём несколько строк, то передвиньте курсор на строку, которая начинается с

1.2 Посмотрите, встречаются ли в этой строке «quiet» и «splash»?

1.3 Уберите обе эти строки и начните загрузку (кнопку F10). Посмотрите, какие именно ошибки не дают загрузиться системе.

2) Как просмотреть журнал последней загрузки

Если ваш Linux не загружается или загружается в чёрный экран, то начните с переключения на другой терминал сочетаниями клавиш Ctrl+Alt+F1, Ctrl+Alt+F2, Ctrl+Alt+F3 и так далее. Если вам это удалось и вы увидели приглашение ввести учётные данные для входа в систему, то дальше всё элементарно — выполните вход и откатите изменения, из-за которых система не запускается.

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

Если вам удалось войти в систему, пусть даже только с интерфейсом командной строки, то используйте команду journalctl для вывода журнала загрузки:

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

Либо используйте следующую команду для сохранения информации о последней загрузки в файл:

Для просмотра текущего лога X сервера:

Для просмотра журнала предпоследней загрузки X сервера:

Статус служб вы также можете посмотреть командами вида:

Источник

Исправление ошибок Linux

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

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

Все это мы рассмотрим ниже, но сначала общее введение и немного теории.

Решение проблем Linux

Linux очень сильно отличается от WIndows, это заметно также при возникновении проблем Linux. Вот допустим, произошла ошибка в программе Windows, она полностью закрывается или выдает непонятное число с кодом ошибки и все, вы можете только догадываться или использовать поиск Google, чтобы понять что произошло. Но в Linux все совсем по-другому. Здесь каждая программа создает лог файлы, в которых мы можем при достаточном знании английского или даже без него, выяснить, что произошло. Более того, если программу запускать из терминала, то все ошибки linux и предупреждения мы увидим прямо в окне терминала. и сразу можно понять что нужно делать.

Причем вы сможете понять что произошло, даже не зная английского. Главным признаком ошибки есть слово ERROR (ошибка) или WARNING (предупреждение). Рассмотрим самые частые сообщения об ошибках:

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

Проблемы с командами в терминале

Обычно проблемы с командами в терминале возникают не из-за ошибки linux или потому, что разработчики что-то недоработали, а потому, что вы ввели что-то неправильно или предали не те что нужно опции.

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

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

Очень распространенной среди новичков ошибкой, есть no such file or directory при попытке выполнить файл, скачанный из интернета. Сразу кажется что это бред, ведь файл существует, но на самом деле оболочка ищет только файлы с флагом исполняемый, а поэтому пока вы не установите этот флаг для файла, он для оболочки существовать не будет.

Проблемы в программах

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

Многие ошибки системы linux, связанные с графической оболочкой вы можете найти в файле

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

Также ошибки linux могут возникать не только в обычных программах но и в работающих в фоне сервисах. Но их тоже можно решить, чтобы посмотреть сообщения, генерируемые сервисом, запущенным с помощью systemd, просто наберите команду просмотра состояния сервиса:

$ sudo systemctl status имя_сервиса

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

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

Проблемы с драйверами и ядром

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

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

Чтобы иметь возможность удобно листать вывод можно выполнить:

Или сразу выбрать все ошибки:

sudo dmesg | grep error

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

Проблемы с графической оболочкой

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

При проблемах с графической оболочкой вы можете всегда переключиться в режим терминала с помощью сочетания клавиш Ctrl+Alt+F1. Далее, вам нужно ввести логин и пароль, затем можете вводить команды терминала.

Посмотреть логи графической оболочки вы можете в том же файле

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

Проблемы с диском и файловой системой

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

Выводы

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

Источник

Как определить и исправить проблемы с загрузкой в Linux

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

Поэтому наблюдение за проблемами загрузки / ошибками становится для нас проблемой.

В этой статье мы кратко объясним различные этапы процесса загрузки системы Linux, а затем узнаем, как установить и решить проблемы с загрузкой.

Краткое описание процесса загрузки Linux

Итак, как только мы нажмем кнопку Power On, BIOS (Basic Input Output System), программа встроенная в материнскую плату, выполняет POST (Power on Self Test) – где такие аппаратные средства, как диски, оперативная память (Random Access Memory), клавиатура, и т. д. сканируются.

В случае ошибки (отсутствие / неисправное оборудование), это сообщается на экране.

Во время POST BIOS также ищет загрузочное устройство, на котором установлен диск (обычно первый жесткий диск, однако мы можем настроить его как DVD, USB, сетевую карту и т. д).

Затем система подключится к диску и выполнит поиск основной загрузочной записи (размером 512 байт), в которой хранится загрузчик (размер 446 байт), а остальная часть пространства хранит информацию о дисковых разделах (четыре максимум) и MBR.

Загрузчик будет идентифицировать и указывать на него, а также загружать ядро и файл initrd (диск с инициализацией) – который обеспечивает доступ ядра к установленной корневой файловой системе и модулям / драйверам, хранящимся в каталоге / lib), которые обычно хранятся в каталоге /boot файловой системы.

После загрузки ядра он запускает init (или systemd на более новых дистрибутивах Linux), первый процесс с PID 1, который, в свою очередь, запускает все остальные процессы в системе.

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

Как определить проблемы загрузки Linux или сообщения об ошибках

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

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

/var/log/boot.log – регистрирует сообщения загрузки системы

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

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

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

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

Проблема: проблема с разделом подкачки; система либо не прочитала файл подкачки / устройство / раздел, либо его нет.

Давайте проверим, использует ли система пространство подкачки с командой free.

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

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

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

/var/log/messages – Общие системные журналы

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

Чтобы просмотреть его, введите:

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

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

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

dmesg – Показывает сообщения ядра

Команда dmesg может показывать операции после завершения процесса загрузки, такие как параметры командной строки, переданные ядру; обнаруженные аппаратные компоненты, события при добавлении нового USB-устройства или ошибки, такие как сбои сетевого адаптера (Network Interface Card), что драйверы не сообщают о активности канала в сети и о многом другом.

journalctl – Содержимое журнала Systemd

Эти сообщения включают сообщения ядра и загрузки; сообщения из syslog или различных служб.

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

Вышеприведенный пример вывода команды показывает ошибку, которую мы уже идентифицировали, просмотрев /var/log/boot.log: ошибка раздела подкачки.

Чтобы просмотреть больше выходных строк, просто нажмите кнопку [Ввод].

Источник

Не загружается Linux

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

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

Почему Linux не загружается?

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

Проверка журналов загрузки

Итак, вы загрузились с LiveUSB системы и подключили разделы с основной системой или же вошли в режим восстановления с помощью загрузчика Grub. Для этого есть специальная опция в большинстве дистрибутивов. Она загружает однопользовательский режим Systemd с поддержкой сети и минимальными возможностями. С помощью него вы можете вернуть систему к нормальной работе.

Для работы в этом режиме нужно ввести пароль суперпользователя.

Если такого пункта нет можно загрузить режим восстановления Bash. Для этого нужно нажать клавишу «E» на пункте меню Grub и дописать в строку параметров ядра «init=/bin/bash»:

В режиме восстановления можно посмотреть содержимое лога ядра с помощью dmesg, в LiveUSB это бесполезно:

Еще кое-какую информацию можно получить из файла /var/log/messages, в котором хранятся общесистемные сообщения от различных сервисов, в том числе во время загрузки:

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

Что делать если Linux не грузится?

1. Проблема с местом на диске

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

Если доступно 0% места, то вы знаете в чем проблема. Чтобы ее решить просто удалите ненужные файлы из папок /var/log, /var/cache/ и так далее. Для того чтобы вы смогли редактировать и удалять файлы, корневую систему, возможно, придется перемонтировать для чтения и записи:

2. Целостность пакетов и системы

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

Также можно выполнить:

Но это сработает только в chroot окружении LiveUSB системы, поскольку в режиме восстановления интернета нет. Вы можете попытаться настроить проводной интернет с помощью команды:

3. Проблема с /etc/fstab

Следующая причина проблем с загрузкой может быть неверная запись в /etc/fstab для одного из разделов, если лог сообщает что-то в роде «Dependency failed for /dev/disk/by-uuid/f4d5ddc4-584c-11e7-8a55-970a85f49bc5» то это означает, что система не может примонтировать один из разделов в /etc/fstab.

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

Поэтому если есть такая ошибка в логе проверьте файл /etc/fstab. Правильно ли там указан адрес корневого раздела? Если не уверены, лучше заменить на привычную запись Linux без UUID.

4. Повреждение файловой системы

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

Здесь нужно указать адрес файла нужного раздела в файловой системе.

5. Проблема видеодрайвера

Если вы обновляли систему или устанавливали проприетарный драйвер, а потом в логах загрузки увидели ошибку запуска драйвера, то проблема в нем. Такое происходит потому что проприетарные драйвера не всегда совместимы с самыми новыми версиями ядер. Для решения проблемы достаточно удалить драйвер из системы в режиме восстановления. Например, для Nvidia:

Для видеокарт AMD команда будет выглядеть так:

С новым драйвером AMDGPU проблем быть не должно, так как он имеет открытый исходный код и встроен в ядро.

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

6. Другое

Если у вас все же проблемы с загрузчиком Grub, вы можете использовать инструмент BootRepair для восстановления или просмотрите статью как восстановить Grub2 вручную. Также, возможно, вас заинтересует статья: ускорение загрузки Linux.

Выводы

Источник

Лог файлы Linux по порядку

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

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

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

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

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

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

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

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

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

/.xsession-errors — Вывод stderr графических приложений X11.

/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

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

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

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

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

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

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

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