Посмотреть ошибки загрузки linux

Как посмотреть ошибки при чёрном экране в Linux

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

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

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

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

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

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

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

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

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

Загрузочная флэшка Linux на Windows

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

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

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

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

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

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

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

К ним относятся:

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

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

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

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

# cat /var/log/boot.log

[  OK  ] Started Load/Save RF Kill Switch Status.
[ TIME ] Timed out waiting for device dev-disk-byx2duuid-53e41ce9x2ddc18x2d458cx2dbc08x2d584c208ed615.device.
[DEPEND] Dependency failed for /dev/disk/by-uuid/53e41ce9-dc18-458c-bc08-584c208ed615.
[DEPEND] Dependency failed for Swap.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on UUID daemon activation socket.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Listening on CUPS Scheduler.
[  OK  ] Started Daily apt activities.
[  OK  ] Reached target Timers.
[  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
[  OK  ] Started ACPI Events Check.
[  OK  ] Started Trigger resolvconf update for networkd DNS.
[  OK  ] Started CUPS Scheduler.
[  OK  ] Reached target Paths.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Listening on ACPID Listen Socket.
Starting Console System Startup Logging...
[  OK  ] Listening on Cockpit Web Service Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
Starting LSB: Set the CPU Frequency Scaling governor to "ondemand"...
[  OK  ] Started ACPI event daemon.
[  OK  ] Started mintsystem.service.
Starting Detect the available GPUs and deal with any system changes...
Starting LSB: daemon to balance interrupts for SMP systems...
Starting Bluetooth service...
[  OK  ] Started ClamAV virus database updater.
Starting LSB: Starts syslogd...
[  OK  ] Started Regular background program processing daemon.
Starting Modem Manager...
Starting Accounts Service...
......

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

[DEPEND] Dependency failed for /dev/disk/by-uuid/53e41ce9-dc18-458c-bc08-584c208ed615.
[DEPEND] Dependency failed for Swap.

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

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

# free
total        used        free      shared  buff/cache   available
Mem:        3742792     2421060      433696      287376      888036      967000
Swap:             0           0           0

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

# swapon -s

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

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

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

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

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

# cat /var/log/messages

Jun  4 13:04:44 tecmint syslogd (GNU inetutils 1.9.4): restart
Jun  4 13:19:55 tecmint -- MARK --
Jun  4 13:39:55 tecmint -- MARK --
Jun  4 13:59:55 tecmint -- MARK --
Jun  4 14:19:55 tecmint -- MARK --
Jun  4 14:20:17 tecmint vmunix: [ 4945.388740] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Jun  4 14:20:17 tecmint vmunix: [ 4945.388837] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Jun  4 14:20:17 tecmint vmunix: [ 4945.388903] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Jun  4 14:20:17 tecmint vmunix: [ 4945.388930] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Jun  4 14:20:17 tecmint vmunix: [ 4945.389334] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Jun  4 14:20:17 tecmint vmunix: [ 4945.389402] pcieport 0000:00:1c.0: BAR 15: assigned [mem 0xdfa00000-0xdfbfffff 64bit pref]
.....

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

# more /var/log/messages

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

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

# ls -l message*
-rw-r--r-- 1 root root 1206127 Jun 10 14:20 messages
-rw-r--r-- 1 root root 1419494 Jun  4 13:00 messages.1
-rw-r--r-- 1 root root  153011 May 28 09:30 messages.2.gz

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

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

# dmesg

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=57b36d48-1938-43c2-bf85-e97bc9f423ea ro quiet splash
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[    0.000000] x86/fpu: Using 'eager' FPU context switches.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000090000-0x00000000000bffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000040005000-0x0000000080b2ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000080b30000-0x0000000080d31fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000080d32000-0x00000000ce3eefff] usable
[    0.000000] BIOS-e820: [mem 0x00000000ce3ef000-0x00000000ce5eefff] type 20
[    0.000000] BIOS-e820: [mem 0x00000000ce5ef000-0x00000000daeeefff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000daeef000-0x00000000daf9efff] ACPI NVS
....

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

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

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

# journalctl

Jun 13 16:35:32 tecmint mtp-probe[963]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:1d.0/u
Jun 13 16:35:32 tecmint mtp-probe[963]: bus: 2, device: 5 was not an MTP device
Jun 13 16:35:54 tecmint systemd[1]: dev-disk-byx2duuid-53e41ce9x2ddc18x2d458cx2dbc08x2d584c208ed615.
Jun 13 16:35:54 tecmint systemd[1]: Timed out waiting for device dev-disk-byx2duuid-53e41ce9x2ddc18x2d
Jun 13 16:35:54 tecmint systemd[1]: Dependency failed for /dev/disk/by-uuid/53e41ce9-dc18-458c-bc08-584c2
Jun 13 16:35:54 tecmint systemd[1]: Dependency failed for Swap.
Jun 13 16:35:54 tecmint systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
Jun 13 16:35:54 tecmint systemd[1]: dev-disk-byx2duuid-53e41ce9x2ddc18x2d458cx2dbc08x2d584c208ed615.
Jun 13 16:35:54 tecmint systemd[1]: dev-disk-byx2duuid-53e41ce9x2ddc18x2d458cx2dbc08x2d584c208ed615.
Jun 13 16:35:54 tecmint systemd[1]: Reached target System Initialization.
Jun 13 16:35:54 tecmint systemd[1]: Started ACPI Events Check.
Jun 13 16:35:54 tecmint systemd[1]: Listening on CUPS Scheduler.
Jun 13 16:35:54 tecmint systemd[1]: Starting Console System Startup Logging...
Jun 13 16:35:54 tecmint systemd[1]: Started Daily Cleanup of Temporary Directories.

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

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

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 очень мощный и гибкий инструмент, и если вы знаете как его использовать, он может сделать вашу жизнь намного проще во время поиска причин проблем с системой или ее сервисами.