I want to find the cause of a boot problem I have tried
ls -ltr /var/log from antony@antony which gives me login incorrect
can someone tell me what command to use to see what has upset the boot thanks
NB when trying some commands from antony@antony then password I get login incorrect.
Is that right?
asked Dec 29, 2011 at 13:54
AntonyAntony
1,3133 gold badges14 silver badges19 bronze badges
1
For systemd based versions of Ubuntu (15.04 onwards) you’ll need to use the journalctl command to view the current boot log messages (as mentioned in this answer, and here for more info on how to enable them for previous boots):
journalctl -b
answered Sep 6, 2016 at 18:48
PierzPierz
2,8651 gold badge23 silver badges14 bronze badges
2
You can use two log files to view the boot problem.
/var/log/boot.log --- System boot log
/var/log/dmesg --- print or control the kernel ring buffer
answered Dec 29, 2011 at 14:50
MughilMughil
1,61212 silver badges16 bronze badges
3
To view kernel messages…
dmesg
or to page through the messages…
dmesg | less
The program helps users to print out their kernel messages. Instead of
copying the messages by hand, the user only needs to enter at the console:
$ dmesg > kernel.messages
and mail thekernel.messagesfile to whoever can debug their problem.
answered Dec 29, 2011 at 14:15
1
I am using sudo dmesg -T --color=always --level=err,warn | more to see kernel errors and warnings
answered May 23, 2022 at 6:09
ShobeiraShobeira
1332 silver badges12 bronze badges
Trying to add to previous useful answers, boot log is populated with many rows. Only a few of then will help you fixing the issue. Filter the reading of the most appropriate log file with grep may speed up your research.
In my case, issue keyword was «hid», so gave me the very rows I was interested in:
a@acero:~$
journalctl -b | grep hid
Jul 01 07:40:50 acero kernel: hid: raw HID events driver (C) Jiri Kosina
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: can't add hid device: -61
Jul 01 07:41:05 acero kernel: hid-generic 0003:10C4:8108.0001: input,hidraw0: USB HID v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on usb-0000:03:00.3-2/input0
answered Jul 1, 2022 at 5:50
AugustoAugusto
4173 silver badges15 bronze badges
Приветствую читателей своего сайта. Сегодня я всесторонне рассмотрю тему тему логов в Ubuntu — ошибки, загрузка, системные логи, cron и остальное. Постараюсь дать обзорную информацию по основным моментам в этой теме. Материал в основном рассчитан на новичков, но возможно восполнит пробелы и специалистов.
Традиционно логи в Linux хранятся в директории /var/log. Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.
- syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
- auth.log — лог авторизации и аутентификации в системе.
- dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
- alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
- kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
- maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
- dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
- lastlog и wtmp — информация о прошлых авторизациях пользователей.
Лог загрузки
Начнем с самого начала. В момент загрузки системы записывается вся основная информация, имеющая к ней отношение. Если у вас будут какие-то ошибки во время старта сервера, вы сможете их увидеть в этом логе. Посмотреть лог загрузки Ubuntu можно следующим образом.
sudo dmesg
У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске.
sudo dmesg | grep sda
Вы увидите лог загрузки системы ubuntu, содержащий информацию только о диске sda. Аналогичным образом можно фильтровать вывод по другим темам. Например, посмотреть все ошибки, которые были во время загрузки.
sudo dmesg | grep error
И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg.
Логи авторизации, в том числе ssh
Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log. Авторизация по ssh там будет выглядеть следующим образом.
sshd[2774]: Accepted publickey for root from 21.17.214.129 port 2673 ssh2: RSA SHA256:MCDja9Ve7rYZCzeVGpYXpqRxfAanWwVkcd+lU3GS sshd[2774]: pam_unix(sshd:session): session opened for user root by (uid=0) systemd-logind[628]: New session 6 of user root.
Здесь мы видим ip адрес, с которого произошло подключение и слепок сертификата, так как аутентификация была произведена с его помощью. Если хотите повысить уровень логирования подключений по ssh и получать больше информации, то можете отредактировать конфигурационный файл sshd — /etc/ssh/sshd_config, добавив туда следующий параметр.
LogLevel VERBOSE
Не забудьте перезапустить службу sshd для принятия изменений:
sudo systemctl restart sshd
После этого логирование подключений по ssh будет более подробное.
Лог локального входа в ubuntu тоже хранится в файле auth.log. Информация о подключении через консоль выглядит следующим образом.
login[680]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) systemd-logind[628]: New session 9 of user root. login[3094]: ROOT LOGIN on '/dev/tty1'
Устройство /dev/tty1 говорит о том, что вход локальный.
Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog.
Примерно то же самое можно увидеть с помощью utmpdump.
sudo utmpdump /var/log/wtmp
Логи ошибок в Ubuntu
Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:
- error или err
- critical или crit
- debug
- warn
Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (warn).
sudo dmesg -l warn
А теперь проверим ошибки в системном логе.
sudo cat /var/log/syslog | grep error
Видим некоторые ошибки в службе systemd-resolved.
Cron logs
Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.
Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.
cron.* /var/log/cron.log
По умолчанию, она присутствует в конфиге, но закомментирована. Вам нужно убрать # в начале строки, чтобы раскомментировать ее. Так же я рекомендую сделать так, чтобы эти логи не дублировались в общий системный лог. Для этого немного измените следующую строку.
*.*;auth,authpriv.none,cron.none -/var/log/syslog
Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.
sudo systemctl restart rsyslog sudo systemctl restart cron
Проверяем cron.log
sudo cat /var/log/cron.log
Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.
Лог действий пользователя
Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.
Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers. Добавляем туда строку.
Defaults logfile=/var/log/sudo.log
Теперь выполните какую-нибудь команду через sudo.
sudo cat /var/log/cron.log
Проверяем sudo.log.
Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ;
COMMAND=/usr/bin/cat /var/log/cron.log
Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.
На сегодня по логам в Ubuntu у меня все. Желаю вам логов без ошибок и вечного аптайма (шутка, надо ставить обновы и перезагружаться).
Приветствую читателей своего сайта. Сегодня я всесторонне рассмотрю тему тему логов в Ubuntu — ошибки, загрузка, системные логи, cron и остальное. Постараюсь дать обзорную информацию по основным моментам в этой теме. Материал в основном рассчитан на новичков, но возможно восполнит пробелы и специалистов.
Традиционно логи в Linux хранятся в директории /var/log. Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.
- syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
- auth.log — лог авторизации и аутентификации в системе.
- dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
- alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
- kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
- maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
- dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
- lastlog и wtmp — информация о прошлых авторизациях пользователей.
Лог загрузки
Начнем с самого начала. В момент загрузки системы записывается вся основная информация, имеющая к ней отношение. Если у вас будут какие-то ошибки во время старта сервера, вы сможете их увидеть в этом логе. Посмотреть лог загрузки Ubuntu можно следующим образом.
sudo dmesg
У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске.
sudo dmesg | grep sda
Вы увидите лог загрузки системы ubuntu, содержащий информацию только о диске sda. Аналогичным образом можно фильтровать вывод по другим темам. Например, посмотреть все ошибки, которые были во время загрузки.
sudo dmesg | grep error
И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg.
Логи авторизации, в том числе ssh
Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log. Авторизация по ssh там будет выглядеть следующим образом.
sshd[2774]: Accepted publickey for root from 21.17.214.129 port 2673 ssh2: RSA SHA256:MCDja9Ve7rYZCzeVGpYXpqRxfAanWwVkcd+lU3GS sshd[2774]: pam_unix(sshd:session): session opened for user root by (uid=0) systemd-logind[628]: New session 6 of user root.
Здесь мы видим ip адрес, с которого произошло подключение и слепок сертификата, так как аутентификация была произведена с его помощью. Если хотите повысить уровень логирования подключений по ssh и получать больше информации, то можете отредактировать конфигурационный файл sshd — /etc/ssh/sshd_config, добавив туда следующий параметр.
LogLevel VERBOSE
Не забудьте перезапустить службу sshd для принятия изменений:
sudo systemctl restart sshd
После этого логирование подключений по ssh будет более подробное.
Лог локального входа в ubuntu тоже хранится в файле auth.log. Информация о подключении через консоль выглядит следующим образом.
login[680]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) systemd-logind[628]: New session 9 of user root. login[3094]: ROOT LOGIN on '/dev/tty1'
Устройство /dev/tty1 говорит о том, что вход локальный.
Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog.
Примерно то же самое можно увидеть с помощью utmpdump.
sudo utmpdump /var/log/wtmp
Логи ошибок в Ubuntu
Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:
- error или err
- critical или crit
- debug
- warn
Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (warn).
sudo dmesg -l warn
А теперь проверим ошибки в системном логе.
sudo cat /var/log/syslog | grep error
Видим некоторые ошибки в службе systemd-resolved.
Cron logs
Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.
Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.
cron.* /var/log/cron.log
По умолчанию, она присутствует в конфиге, но закомментирована. Вам нужно убрать # в начале строки, чтобы раскомментировать ее. Так же я рекомендую сделать так, чтобы эти логи не дублировались в общий системный лог. Для этого немного измените следующую строку.
*.*;auth,authpriv.none,cron.none -/var/log/syslog
Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.
sudo systemctl restart rsyslog sudo systemctl restart cron
Проверяем cron.log
sudo cat /var/log/cron.log
Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.
Лог действий пользователя
Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.
Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers. Добавляем туда строку.
Defaults logfile=/var/log/sudo.log
Теперь выполните какую-нибудь команду через sudo.
sudo cat /var/log/cron.log
Проверяем sudo.log.
Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ;
COMMAND=/usr/bin/cat /var/log/cron.log
Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.
На сегодня по логам в Ubuntu у меня все. Желаю вам логов без ошибок и вечного аптайма (шутка, надо ставить обновы и перезагружаться).
I want to find the cause of a boot problem I have tried
ls -ltr /var/log from antony@antony which gives me login incorrect
can someone tell me what command to use to see what has upset the boot thanks
NB when trying some commands from antony@antony then password I get login incorrect.
Is that right?
asked Dec 29, 2011 at 13:54
AntonyAntony
1,2133 gold badges14 silver badges19 bronze badges
1
For systemd based versions of Ubuntu (15.04 onwards) you’ll need to use the journalctl command to view the current boot log messages (as mentioned in this answer, and here for more info on how to enable them for previous boots):
journalctl -b
answered Sep 6, 2016 at 18:48
PierzPierz
2,7451 gold badge21 silver badges14 bronze badges
2
You can use two log files to view the boot problem.
/var/log/boot.log --- System boot log
/var/log/dmesg --- print or control the kernel ring buffer
answered Dec 29, 2011 at 14:50
MughilMughil
1,57211 silver badges16 bronze badges
3
To view kernel messages…
dmesg
or to page through the messages…
dmesg | less
The program helps users to print out their kernel messages. Instead of
copying the messages by hand, the user only needs to enter at the console:
$ dmesg > kernel.messages
and mail thekernel.messagesfile to whoever can debug their problem.
answered Dec 29, 2011 at 14:15
1
I am using sudo dmesg -T --color=always --level=err,warn | more to see kernel errors and warnings
answered May 23, 2022 at 6:09
ShobeiraShobeira
1111 silver badge11 bronze badges
Trying to add to previous useful answers, boot log is populated with many rows. Only a few of then will help you fixing the issue. Filter the reading of the most appropriate log file with grep may speed up your research.
In my case, issue keyword was «hid», so gave me the very rows I was interested in:
a@acero:~$
journalctl -b | grep hid
Jul 01 07:40:50 acero kernel: hid: raw HID events driver (C) Jiri Kosina
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: failed to reset device: -61
Jul 01 07:40:50 acero kernel: i2c_hid_acpi i2c-SYNA7DB5:01: can't add hid device: -61
Jul 01 07:41:05 acero kernel: hid-generic 0003:10C4:8108.0001: input,hidraw0: USB HID v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on usb-0000:03:00.3-2/input0
answered Jul 1, 2022 at 5:50
AugustoAugusto
4173 silver badges15 bronze badges
Система 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: ошибка раздела подкачки.
Чтобы просмотреть больше выходных строк, просто нажмите кнопку [Ввод].
где посмотреть журнал ошибок при загрузке?
Автор andrei186, 11 января 2016, 21:28:45
« назад — далее »
0 Пользователи и 1 гость просматривают эту тему.
Деб-8 отказался загружаться, выдав несколько экранов ошибок. В конце попросил рутовый пароль, чтобы произвести какой-то maintenance. С этим паролем позволил войти в командную строку.
Где теперь я могу посмотреть эти ошибки?
Пробовал в /var/log/syslog — файл нескончаемой длины, и обрывается на 28/12/2015
/var/log/dmesg — то же самое
/var/log/boot.log отсутствует
Цитата: Yrii от 11 января 2016, 21:51:45
Цитата: andrei186 от 11 января 2016, 21:28:45Где теперь я могу посмотреть эти ошибки?
Например можно воспользоваться новой «фишкой»:
journalctl -b -p err
эта команда вернула, что такая команда не найдена.
Гугл учит, что journalctl есть часть пакета systemd
apt-get install systemd ответила одним предупреждением и двумя ошибками:
W: not using locking for read only lock file /var/lib/dpkg/lock
E: unable to write to /var/cache/apt
E: the package lists of status file could not be parced or opened
Все же можно посмотреть эти журналы ошибок без фишек?
andrei186, У тебя Debian 8, значит systemd (при установке по умолчанию) у тебя присутствует (опять же, если сам не удалял)
journalctl -b -p err надо запускать с правами root (так же как и команду установки пакетов )
ЦитироватьВсе же можно посмотреть эти журналы ошибок без фишек?
Например тут /var/log/syslog
Цитата: Yrii от 14 января 2016, 20:51:22
andrei186, У тебя Debian 8, значит systemd (при установке по умолчанию) у тебя присутствует (опять же, если сам не удалял)journalctl -b -p errнадо запускать с правами root (так же как и команду установки пакетов)
ЦитироватьВсе же можно посмотреть эти журналы ошибок без фишек?
Например тут /var/log/syslog
спасибо, но в моем первоначальном посте я сообщил, что я был допущен до командной строки как root, и что я уже смотрел /var/log/syslog, записи в котором заканчиваются на 28/12/2015, а ошибки, о которых речь, начались 11 января 2016.
Как я сказал, этот файл неимоверной длины — может у него есть ограничение по размеру, и он не принимает новых записей, и тогода его надо прчистить?
Цитата: andrei186 от 14 января 2016, 21:09:47Как я сказал, этот файл неимоверной длины — может у него есть ограничение по размеру, и он не принимает новых записей, и тогода его надо прчистить?
По умолчанию он сам должен произвести ротацию логов.
Цитата: andrei186 от 14 января 2016, 20:30:38
эта команда вернула, что такая команда не найдена.
Постарайтесь писать дословно, что пишет. (Просто может быть вы что-то не так поняли /перевели. Всякое бывает.)
Посмотрите ещё файл /var/log/kern.log
- Русскоязычное сообщество Debian GNU/Linux
- ►
- ►
Общие вопросы - ►
где посмотреть журнал ошибок при загрузке?
Системы Linux загружаются очень быстро, поэтому большая часть данных, выводимых во время загрузки, быстро прокручивается и мы не успеваем прочитать текст. Тем не менее, во время загрузки, могут возникнуть различные ошибки, вплоть до того, что вы столкнетесь с проблемой не загружается Linux.
Ошибка может возникнуть в любом месте загрузки и любом компоненте системы инициализации. Обычно, systemd выводит подробную информацию об ошибках загрузки Linux на экран, но не всегда можно успеть их все прочитать. В этой статье мы рассмотрим что делать если не загружается Linux после установки, а также как посмотреть логи загрузки в этой операционной системе.
Причин проблем с загрузкой Linux может быть большое количество, в этой статье мы рассмотрим самые частые из них, которые можно достаточно просто решить. Сначала кратко пройдемся по самим причинам:
- Linux после обновления не загружается, вы обновляли дистрибутив и что-то пошло не так, и теперь вы не можете попасть в вашу рабочую оболочку;
- Linux перестал загружаться в результате повреждения файловой системы;
- Linux не может примонтировать один из важных разделов диска из-за неверных настроек fstab;
- Система не загружается из-за несовместимости графического драйвера и ядра;
- Диск переполнен и системе попросту негде создать временные файлы.
Все это может возникать не так редко, если вы очень любите экспериментировать с системой и при этом не очень аккуратны. Мы не будем рассматривать проблемы с загрузкой из за Grub. Я буду надеяться, что там у вас все в порядке. Самое главное, что нужно сделать при проблемах с загрузкой — это посмотреть внимательно логи последней загрузки. Только так вы сможете понять в чем причина проблем и не гадать. Как это сделать? Есть несколько способов, вы можете использовать LiveCD или загрузиться в режим восстановления.
Проверка журналов загрузки
Итак, вы загрузились с LiveUSB системы и подключили разделы с основной системой или же вошли в режим восстановления с помощью загрузчика Grub. Для этого есть специальная опция в большинстве дистрибутивов. Она загружает однопользовательский режим Systemd с поддержкой сети и минимальными возможностями. С помощью него вы можете вернуть систему к нормальной работе.
Для работы в этом режиме нужно ввести пароль суперпользователя.
Если такого пункта нет можно загрузить режим восстановления Bash. Для этого нужно нажать клавишу «E» на пункте меню Grub и дописать в строку параметров ядра «init=/bin/bash»:
С этим параметром ядро запустит интерпретатор Bash вместо того, чтобы загружать систему инициализации. Самый первый способ посмотреть логи в systemd — это использовать утилиту journalctl. Система нам сама подсказывает какую команду нужно запустить, чтобы посмотреть логи:
journalctl -xb
Если во время загрузки возникла ошибка, вы найдете ее здесь. Если же вы пошли другим путем, можно посмотреть несколько файлов, первый из них — /var/log/boot.log. Он есть не во всех дистрибутивах, но если есть, то здесь вы найдете все сообщения, которые выводились на экран во время загрузки:
cat /var/log/boot.log
В режиме восстановления можно посмотреть содержимое лога ядра с помощью dmesg, в LiveUSB это бесполезно:
dmesg
Еще кое-какую информацию можно получить из файла /var/log/messages, в котором хранятся общесистемные сообщения от различных сервисов, в том числе во время загрузки:
cat /var/log/messages
Все дальнейшие действия по восстановлению загрузки Linux нужно выполнять опираясь на информацию, полученную из лог файлов, только так вы сможете решить проблему.
1. Проблема с местом на диске
Предположим, что вы обновляли систему и она перестала загружаться после этого. Тогда можно предположить два варианта, либо загрузка обновлений переполнила корневой раздел и теперь системе некуда писать файлы, либо обновление прошло не очень успешно и важные пакеты повреждены. Сначала посмотрим свободное место на диске:
df -h
Если доступно 0% места, то вы знаете в чем проблема. Чтобы ее решить просто удалите ненужные файлы из папок /var/log, /var/cache/ и так далее. Для того чтобы вы смогли редактировать и удалять файлы, корневую систему, возможно, придется перемонтировать для чтения и записи:
mount -o remount,rw /
2. Целостность пакетов и системы
У меня с местом все в порядке, доступно более 5 гигабайт, значит можно предположить, что проблема в пакетах. Чтобы исправить выполните dpkg:
dpkg --configure -a
Также можно выполнить:
sudo apt -f install
# sudo apt update && sudo apt full-upgrade
Но это сработает только в chroot окружении LiveUSB системы, поскольку в режиме восстановления интернета нет. Вы можете попытаться настроить проводной интернет с помощью команды:
dhclient
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. Повреждение файловой системы
Обычно файловая система проверяется автоматически, но это обычно. Если вы отключили эту функцию, а потом произошло неожиданное отключение компьютера, файловая система будет повреждена, а восстановить ее будет некому. Поэтому при ошибках монтирования еще можно попытаться проверить файловые системы на ошибки:
fsck -a /dev/sda5
Здесь нужно указать адрес файла нужного раздела в файловой системе.
5. Проблема видеодрайвера
Если вы обновляли систему или устанавливали проприетарный драйвер, а потом в логах загрузки увидели ошибку запуска драйвера, то проблема в нем. Такое происходит потому что проприетарные драйвера не всегда совместимы с самыми новыми версиями ядер. Для решения проблемы достаточно удалить драйвер из системы в режиме восстановления. Например, для Nvidia:
apt purge nvidia*
Для видеокарт AMD команда будет выглядеть так:
apt purge fglrx*
С новым драйвером AMDGPU проблем быть не должно, так как он имеет открытый исходный код и встроен в ядро.
Во всяком случае, после удаления драйвера черный экран Linux должен перестать появляться.
6. Другое
Если у вас все же проблемы с загрузчиком Grub, вы можете использовать инструмент BootRepair для восстановления или просмотрите статью как восстановить Grub2 вручную. Также, возможно, вас заинтересует статья: ускорение загрузки Linux.
Выводы
В этой статье мы рассмотрели что делать когда не загружается Linux. Как видите, может возникнуть достаточно различных проблем. Но преимущество Linux в том, что вы можете решить все это благодаря прямому доступу к файловой системе. Также, если домашняя папка вынесена в отдельный раздел, то если ничего не сработает — можно переустановить систему с минимальными потерями. Надеюсь, эта информация была полезной.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
Короче, продолжаем. Теперь я для вас подготовил некую уже не маленькую статью, на тему мониторинга Linux систем. В некотором роде эта статья мне будет служить в качестве мини-справочника по необходимым командам, для того, чтобы можно было понимать, все ли нормально с системой. Поговорим об основных командах типа top/htop/uptime/ps, о том где какие логи лежат и что они означают и так далее. Короче, начнем..
Log-файлы (журналы)
Все логи по умолчанию хоронятся в директории /var/log/ (ну так принято по стандарту иерархии файловой системы) и эти файлы — сведения о происходящих процессах в системе. Кстати, если вы поддерживайте систему, которая может быть интересна взломщикам, то настоятельно рекомендуется обзавестись системой дублирования логов, например, на туже почту. Взломщик будет думать, что все «зачистил» за собой, но доказательства его пребывания в системе останутся. Но речь не об этом..
Рассмотрим пример стандартных файлов в директории /var/log/, на примере ОС Debian Linux 7:
- /var/log/syslog — syslog является основным системным журналом и в нем сохраняются сообщения демонов и других программ, работающих в системе, например, dhclient, cron, init, xscreensaver, а также некоторые сообщения ядра. Этот журнал — первое место, откуда надо начинать просмотр при попытке отследить типичные системные ошибки
- /var/log/auth.log — содержит информацию системы авторизации, в том числе логины и механизм проверки подлинности, которые были использованы
- /var/log/daemon.log — содержит информацию о различных демонах/сервисах запущенных в системе. С помощью него можно находить проблемы во время падения системы
- /var/log/dmesg — в файле содержаться все сообщения ядра, начиная с этапа загрузки системы, а просмотреть содержимое этого файла можно используя команду dmesg
- /var/log/kern.log — файл журнала ядра, предоставляет подробный лог сообщений от ядра Linux, которые могут быть полезны при анализе и устранении неисправностей
- /var/log/messages — файл содержит глобальные настройки, в том числе сообщения, которые регистрируются при запуске системы
- /var/log/debug — журнал отладки, предоставляющий подробную отладочную информацию системы и приложений, которые используют syslogd для отладки
- /var/log/user.log — содержит информацию о всех журналах на уровне пользователя
- /var/log/btmp — файл содержит записи обо всех неудавшихся попытках регистрации пользователей в системе. Посмотреть неудачные попытки входа в систему можно с помощью команды lastb
- /var/log/faillog — в этом файле хранится число неудачных попыток входа в систему и их предельное число для каждой учётной записи. А если в консоли ввести команду faillog, то можно увидеть содержимое этого файла
- /var/log/mail.log, /var/log/mail.err, /var/log/mail.info, /var/log/mail.warn — файлы журналирующие почтовые события
- /var/log/lastlog — файл содержащий записи о предыдущих входах в систему
- var/log/apt — директория содержит информацию, которая пишется при установки/удалении пакета с помощью программы apt
- /var/log/alternatives.log — файл программы update-alternatives, которая является механизмом выбора предпочтительного ПО среди нескольких вариантов в таких дистрибутивах Linux, как Debian и Ubuntu
- /var/log/aptitude — файл программы aptitude содержащий информацию об установке/удалении пакетов
- /var/log/dbconfig-common — в случае использования утилиты dbconfig все действия будут журналироваться в файлах, в этой лиректории
- /var/log/dpkg.log — файл содержит информацию, которая пишется при установки/удалении пакета с помощью программы dpkg
- /var/log/fsck — если в вашей системе запускалась проверка файловой системы то она будет журналироваться в файлы находящиеся в этой директории
- /var/log/wtmp — файл содержит двоичные данные о времени регистрации и продолжительность работы всех пользователей системы. Он пользуется командой last для вывода списка регистрировавшихся пользователей
- /var/log/apache2 — если в вашей системе установлен apache, то в данной директории будут находиться журналы access_log и error_log
- /var/log/mysql.err и /var/log/mail.info — если у вас установлена СУБД MySQL, то в этих файлах будут журналироваться сведения о работе и об ошибках СУБД
Теперь приведем пример, что когда нам понадобится..
- Если у нас не запускается какая то служба, то имеет смысл посмотреть файл /var/log/syslog, хотя скажу сразу, туда логируется почти все, даже bind9, если таковой стоит, поэтому лучше смотреть этот файл при помощи «tail -f»:
tail -f /var/log/syslog
- Если есть какие-то проблемы с системой, то можно воспользоваться такими командами, как dmesg, messages, debug
- Все что касается почтовой службы, мы можем просматривать в файлах var/log/mail.log, /var/log/mail.err, /var/log/mail.info, /var/log/mail.warn, но если у вас установлен exim или postfix, то у них уже будут свои log-файлы в своих директориях
- Чтобы понять, кто и когда заходил в систему, можно ввести команду last, все неудачные попытки входа в систему можно увидеть при помощи команды lastb
- Если мы хотим проверить, нормально ли установилось то или иное приложение, то стоит заглянуть в файлы dpkg.log, apt или aptitude (ну все зависит от того, как вы ставили то или иное приложение)
На этом про логи, я думаю, достаточно..
Правки в файлах
Иногда бывает полезно выявлять факты изменения файлов в такой директории, как /etc, особенно, если администрированием сервера занимайтесь не только вы. Сделать это все можно при помощи команды find с параметром -mtime. Например, следующая команда покажет файлы, которые были изменение в течении последних двух суток:
find /etc -mtime 2
Более подробно поиск по различным временам описан тут.
Какова загрузка системы?(LoadAverage)
Вы наверное часто обращали внимание на такую строчку, как LoadAverage, которая показывает числа. Собственно эти числа отображают число блокирующих процессов на исполнение в определенный интервал времени, а именно 1 минута, 5 минут и 15 минут. Под блокирующим процессом подразумевается процесс, который ждет ресурсы для того, чтобы продолжить свою работу, а под ресурсами подразумевается ЦП, дисковая подсистема ввода вывода и сетевая подсистема ввода/вывода.
Не обязательно быть специалистом, чтобы понимать, что высокие показатели LA говорят о том, что система не справляется, например эти цифры могут говорить об аппаратных проблемах.
Чтобы посмотреть эти показания, достаточно воспользоваться командой top или uptime (о top мы поговорим несколько позднее)
[email protected]:~$ uptime 16:54:50 up 5 days, 18:54, 3 users, load average: 0,59, 0,77, 0,84
Большинство (как и я ) будут думать, что чем меньше эти числа, тем лучше, но нужно понимать, когда бить тревогу, если значения этих цифр начнет расти.
Отличная аналогия «на машинках» о том, что эти цифры обозначают приведена в статье на хабре, поэтому приведу краткую выдержку от туда: представим, что одноядерный процессор это однополосный мост, а мы управляем движением на этом мосту. Если мост перегружен, то машины ждут (ну или стоят в пробке). Собственно количество машин в очереди это и есть то число, которое вы видите. Пример можно увидеть на этих картинках из этой прекрасной статьи:
Исходя из того, что мы видим, можно понять, что Load Average равный 1,00 — идеальное значение, но это не так. Идеальным значением для меня можно считать 0,50 ну или на худой конец 0,70, так как должен сохраняться какой-то запас на случай внезапной нагрузки или нештатного поведения той или иной программы.
И имейте в виду, пример выше это пример для одноядерного процессора. Если у вас четырехядерный процессор или два двухядерных процессора, то идеальным LA для вас будет 2,00 или 2,80.
Теперь подытожим эту тему,
- Какое значение лучше смотреть? За минуту, 5 минут или 15 минут?
Если на одноядерном процессоре LA за 5 или 15 минут, то следует на это обратить внимание - Как понять сколько процессоров в системе?
ну тут все просто, нужно отфильтровать grep-ом вывод cpuinfo:[email protected]:~$ cat /proc/cpuinfo | grep 'cpu cores' cpu cores : 2 cpu cores : 2 cpu cores : 2 cpu cores : 2
Что происходит в системе (процессы)
Собственно. чтобы увидеть эти показатели, понять, где у нас есть проблемы, и вообще получить информацию о процессах воспользуемся утилитой top:
Рассмотрим по порядку, что есть что:
- Общая информация:
- текущем времени
- uptime времени (сколько система работает)
- количество пользовательских сессий (3 users)
- LoadAverage (ну о нем написан целый раздел)
- Статистика процессов:
- общее количество процессов в системе
- количество работающих в данный момент процессов
- количество спящих процессов (они работающие, просто «ждут» события)
- количество остановленных событий (я их останавливаю с помощью команды ctrl+z)
- количество процессов, ожидающих родительский процесс для передачи статуса завершения (0 zombie)
- Статистика использования CPU:
- 6,8 us — процент использования центрального процессора пользовательскими процессам
- 1.1 sy — процент использования центрального процессора системными процессами
- 0.0 ni — процент использования центрального процессора процессами с приоритетом, повышенным при помощи вызова nice
- 92.1 id (id это idle cpu time, т.е. время простоя CPU) — процент простоя процессора
- 0.0 wa — процент использования центрального процессора процессами, ожидающими завершения операций ввода-вывода (например чтение/запись на диск)
- 0.0 hi (hi это Hardware IRQ, т.е. аппаратные прерывания) — процент использования центрального процессора обработчиками аппаратных прерываний
- 0.0 si (si это Software Interrupts, т.е. программные прерывания) — процент использования центрального процессора обработчиками программных прерываний
- 0.0 st (st это Steal Time , т.е. заимствованное время) — количество ресурсов центрального процессора «заимствованных» у виртуальной машины гипервизором для других задач (таких, как запуск другой виртуальной машины); это значение будет равно нулю на не использующих виртуальные машины
- Статистика использования физической и swap памяти:
- общее количество памяти (total)
- количество используемой памяти (used)
- количество свободной памяти (free)
- количество памяти в кэше буферов (buffers)
- Список процессов, отсортированный по степени использования центрального процессора (по умолчанию), опишем столбцы:
- PID — идентификатор процесса
- USER — имя пользователя, который является владельцем процесса
- PR — приоритет процесса
- NI — значение «NICE», влияющие на приоритет процесса
- VIRT — объем виртуальной памяти, используемый процессом
- RES — объем физической памяти, используемый процессом
- SHR — объем разделяемой памяти процесса
- S — указывает на статус процесса: S=sleep (ожидает событий) R=running (работает) Z=zombie (ожидает родительский процесс)
- %CPU — процент использования центрального процессора данным процессом (0.3)
- %MEM — процент использования оперативной памяти данным процессом (0.7)
- TIME+ — общее время активности процесса (0:17.75)
- COMMAND — имя процесса (bb_monitor.pl)
Что нам тут интересно? Да интересно почти все :). Например, статистика CPU: высокие значения (более 80%) параметра wa говорят о простое из-за ввода вывода, что может говорить о проблемах с HDD. Кстати, если сложить все эти значения, то у вас получится 100%.
Что мы там можем делать в утилите top?
- Нажав на клавишу k мы можем убить процесс, достаточно будет ввести его PID
- нажав на клавишу u и введя имя пользователя мы можем увидеть все процессы определенного пользователя
- нажав на клавишу b или z и работающие процессы будут выделены цветом
Более подробнее о ключах top можно почитать в страницах man. Кстати, есть еще и отличный аналог утилиты top — htop:
ps — process status
Существует еще генератор снимков процессов ps. Подробнее о нем можно почитать его man, а ниже я приведу примеры использования этой команды:
- при помощи следующей команды мы можем выяснить, выполняется ли в данный момент программа apache:
ps -aux | grep apache
- набрав в терминале следующую команду мы можем получить всю информацию о всех процессах всех пользователей в системе:
ps aux
или
ps -ef
- чтобы увидеть дерево, отображающее иерархические отношения, можно запустить команду с данными параметрами:
ps axjf
- чтобы увидеть процессы определенного пользователя, можно запустить команду с такими параметрами:
ps -f -u www-data
- чтобы увидеть процессы с определенным id, нужно ввести следующее:
[email protected]:~$ ps -f -p 11947,11950,11957 UID PID PPID C STIME TTY TIME CMD www-data 11947 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start www-data 11950 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start www-data 11957 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start
Этого я думаю достаточно. Есть еще масса интересных примеров на просторах интернета, например тут.
В заключение…
начиная писать эту статью, я не думал что все получится на столько громоздко, поэтому еще будет как минимум вторая или третья часть средств мониторинга linux систем.
Источники:
- http://cyberforby.blogspot.ru/2012/04/varlog.html
- http://rus-linux.net/nlib.php?name=/MyLDP/BOOKS/ubuntu_hacks_ru/ubuntuhack82.html
- http://www.thegeekstuff.com/2011/08/linux-var-log-files/
- https://help.ubuntu.com/community/LinuxLogFiles
- http://www.softpanorama.org/Tools/Find/selecting_files_by_age.shtml
- http://habrahabr.ru/post/216827/
- http://habrahabr.ru/post/71020/
- http://habrahabr.ru/post/49204/
- http://rus-linux.net/MyLDP/consol/komanda-top-v-linux.html
- http://linux.die.net/man/1/top
- http://linuxopen.ru/2010/01/21/15-primerov-ispolzovanija-v-linux.html
Содержание
- Как посмотреть ошибки при чёрном экране в Linux
- Исправление ошибок Linux
- Решение проблем Linux
- Проблемы с командами в терминале
- Проблемы в программах
- Проблемы с драйверами и ядром
- Проблемы с графической оболочкой
- Проблемы с диском и файловой системой
- Выводы
- Как определить и исправить проблемы с загрузкой в Linux
- Краткое описание процесса загрузки Linux
- Как определить проблемы загрузки Linux или сообщения об ошибках
- /var/log/boot.log – регистрирует сообщения загрузки системы
- /var/log/messages – Общие системные журналы
- dmesg – Показывает сообщения ядра
- journalctl – Содержимое журнала Systemd
- Не загружается Linux
- Почему Linux не загружается?
- Проверка журналов загрузки
- Что делать если Linux не грузится?
- 1. Проблема с местом на диске
- 2. Целостность пакетов и системы
- 3. Проблема с /etc/fstab
- 4. Повреждение файловой системы
- 5. Проблема видеодрайвера
- 6. Другое
- Выводы
- Лог файлы Linux по порядку
- Основные лог файлы
- И другие журналы
- Чем просматривать — lnav
Как посмотреть ошибки при чёрном экране в 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-а.
Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.
Источник
Система 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: ошибка раздела подкачки.
Чтобы просмотреть больше выходных строк, просто нажмите кнопку [Ввод].