Лог загрузки системы linux

Where can I find the boot log?

When I boot up Ubuntu and I don’t have the graphical boot screen (Plymouth) enabled I see a bunch of text saying if an action was [OK] or it [FAILED]. Since this process is a bit quick I can’t fully read everything, but I would like to know what happens exactly. I think there must be a log file somewhere where all this is written down. But where?

journalctl -b . From the docs: «Show messages from a specific boot. [. ] The argument may be empty, in which case logs for the current boot will be shown.»

3 Answers 3

To see information from your most recent boot, run

To see the details that were logged during a previous boot, just in case you need to compare them with your most recent, run

You will then see results similar to the output shown below, but will need to page to the bottom of the output to see the most recent.

-2 5d45a92d9d5a42d8ae1c8b454f7e1314 Sun 2018-08-19 02:29:21 PDT—Sun 2018-08-19 02:36:26 PDT -1 d5b8ebc236734ee69c48c3809ae452b1 Sun 2018-08-19 02:43:06 PDT—Sun 2018-08-19 07:20:54 PDT 0 6f844406186e4e31ba0375a7bc736242 Sun 2018-08-19 10:43:31 PDT—Sun 2018-08-19 18:54:51 PDT 

At the very bottom of the output, you will see a line that starts with 0, which will represent your most recently logged boot info, the same info you saw when you ran journalctl -b.

To see the data that was logged during the previous boot, copy the identifier from the line that starts with -1 and run the following

journalctl --boot=d5b8ebc236734ee69c48c3809ae452b1 

To go back further in time, just change to -2, -3, -4, etc.

Источник

Основные log файлы в Ubuntu — загрузка, авторизация, ошибки и др.

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

Основные log файлы Ubuntu

Традиционно логи в Linux хранятся в директории /var/log . Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.

1. syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
2. auth.log — лог авторизации и аутентификации в системе.
3. dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
4. alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
5. kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
6. maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
7. dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
8. lastlog и wtmp — информация о прошлых авторизациях пользователей.

Лог загрузки

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

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

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

И так далее. Информация, которую выводит команда 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 , добавив туда следующий параметр.

Не забудьте перезапустить службу 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.

Логи ошибок в Ubuntu

Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:

Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (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 и добавляем туда следующую информацию.

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

*.*;auth,authpriv.none,cron.none -/var/log/syslog

Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.

sudo systemctl restart rsyslog sudo systemctl restart cron

Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.

Лог действий пользователя

Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.

Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers . Добавляем туда строку.

Defaults logfile=/var/log/sudo.log

Теперь выполните какую-нибудь команду через sudo.

Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/cat /var/log/cron.log

Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.

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

Один отзыв для “ Основные log файлы в Ubuntu — загрузка, авторизация, ошибки и др. ”

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

Добавить комментарий Отменить ответ

Свежие записи

Свежие комментарии

• в к записи Как установить и запустить Ubuntu WSL под Windows 10
• Николай к записи Как установить, изменить время и часовой пояс в Ubuntu
• MrToad к записи Установка и настройка KVM в Ubuntu
• MrToad к записи Установка и настройка KVM в Ubuntu
• Александр к записи Как установить, изменить время и часовой пояс в Ubuntu

Источник

How to see log to find a boot problem

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?

5 Answers 5

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):

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 

or to page through the messages.

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 the kernel.messages file to whoever can debug their problem.

I am using sudo dmesg -T —color=always —level=err,warn | more to see kernel errors and warnings

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 

Источник