С 16.04 больше не ведется лог загрузки?

23

Я заметил, что мой /var/log/boot.logфайл имеет дату 2016-04-22, последний раз я загружался в 15.10. Где находятся boot.logфайлы Xenial ?

жасмин
источник
Является ли реальный вопрос не вход в систему, но видя, что замедляет загрузку. Теперь вы используете systemd-analyze blameи / или systemd-analyze critical-chain . Я считаю, что это проще, чем копаться в файлах журналов, чтобы найти причину проблемы.
oldfred
так, никто из вас не может сказать, почему boot.log проводится 2016-04-22 ...? ДЕЙСТВИТЕЛЬНО?
Жасмин
1
@jasmines: К сожалению, мы не можем сказать вам, почему это происходит ... мы не разработчики ... Я обновил свой ответ с некоторой новой информацией с сегодняшнего дня ... вы должны рассмотреть возможность подать отчет об ошибке на Launchpad. :)
cl-netbox
2
journalctl не показывает то, что я вижу в заставке во время загрузки, и мне это нужно
jasmines
1
этот симпатичный журнал с «[FAILED]» красным, вам удалось получить это снова? мой файл с 2017 года ...
Водолей Power

Ответы:

33

использование journalctl

Поскольку journaldсодержит все журналы, вы можете использовать journalctlкоманду с подходящими фильтрами. В случае boot.log, который раньше содержал сообщения от системы инициализации, вы могли бы сделать:

journalctl -b0 SYSLOG_PID=1
  • -b0показывает сообщения от текущей загрузки, -b1от предыдущей загрузки и так далее. Без -bопции journalctlбудут показываться сообщения с начала журнала.
  • SYSLOG_PID фильтрует сообщения из PID 1, он же init.

Или:

journalctl -b0 --system _COMM=systemd
  • _COMM=systemdищет сообщения от systemdкоманды. Так как systemdэто init, это то, что нас интересует.
  • --system фильтрует сообщения из системного журнала вместо журналов пользовательских сессий.

Пример:

muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility 
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static 
lines 1-23

journalctlпо умолчанию открывает журналы в пейджере, так что вам не нужно передавать по каналу less.


Постоянное ведение журнала

Ubuntu по умолчанию не включает постоянные журналы журнала. Благодаря комментарию @Auspex , вам нужно сделать одно из:

  1. Изменить, /etc/systemd/journald.confчтобы включить:

    Storage=persistent
    
  2. Создайте /var/log/journalкаталог вручную:

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

Связанный:

Мур
источник
1
journalctl не показывает то, что я вижу в заставке во время загрузки, и мне это нужно
jasmines
1
Я вижу, что было зарегистрировано в boot.log раньше, в этом формате: [OK] Запущен демон технологии самоконтроля и отчетности (SMART). Монтирование произвольных форматов исполняемых файлов Файловая система ... [OK] Запущена служба входа. Запуск LSB: Запустить демон NTP ... [OK] Запущен стек Avahi mDNS / DNS-SD. [OK] Запущено Сделать удаленные принтеры CUPS доступными локально. [OK] Запущен менеджер модемов. [OK] Запущен сетевой менеджер. Запуск Диспетчера сети Ожидание в сети ... [OK] Достигнута целевая сеть. [OK] Запущена служба учетных записей. и так далее ...
Жасмин
1
Сохраняйте приятный тон и слова. Там будет хорошая политика. Следуй за этим.
Сет
1
journalctl -bX бесполезно для этого, id не содержит сообщений, которые действительно появляются на экране во время загрузки, только boot.log делает и работает только иногда 16.04, единственный способ - сделать фотографию или записать ее. У меня та же проблема.
Майк
1
Как уже упоминалось в jasmines, загрузочные сообщения начинаются с [OK] ... этот материал находится в boot.log, но в journalctl он немного отличается, даже при использовании таких флагов, как -b0 SYSLOG_PID = 1 или -b1 для предыдущей загрузки, не все было там специально ошибки я встречал и нигде не мог найти в логах. Большинство сообщений есть, я не знаю, как воспроизвести эту проблему, поэтому я не могу помочь, но это была ошибка с ядром, и ее не удалось найти, проблема исчезла, но я до сих пор не вижу причины, по которой загружается сообщения не регистрируются точно так, как они появляются на экране.
Майк
3

Я просматривал некоторые сообщения об ошибках и заметил в этом: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771, что Плимут на самом деле пишет в boot.log.

Если вы посмотрите на https://launchpadlibrarian.net/257898272/plymouth-debug.log и поищите в своем браузере «boot.log», вы получите следующие строки:

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

Я не понимаю, как работают внутренние устройства Plymouth, но, поскольку он отвечает за заставку, которая появляется перед экраном входа в систему, я могу только предположить, что, если нет заставки (черный экран), прежде чем перейти к экрану входа , файл не изменен. Если перед экраном входа в систему отображается заставка, вывод процесса загрузки перенаправляется в файл boot.log.

octoquad
источник
К сожалению, у меня есть всплеск, но нет boot.log ...
Жасмин
1
Подтверждаю, что при настройке GRUB_CMDLINE_LINUX_DEFAULT=""в /etc/default/grubчем boot.logне написано. При использовании GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"чем boot.logснова написано. Я использую Ubuntu 19.04.
adrhc
2

В Ubuntu 16.04 boot.logфайл все еще находится в /var/logпапке, как вы можете видеть здесь . Загрузочный лог-файл с сегодняшнего дня (2016-04-29). Возможно, что-то пошло не так, когда вы установили Ubuntu 16.04 или обновили операционную систему с Ubuntu 15.10 до Ubuntu 16.04 LTS.

В качестве альтернативы вы можете изучить общее поведение при загрузке из подробного kern.logфайла. Другой возможной альтернативой может быть ручная настройка демона syslog для создания файла журнала загрузки, и вот руководство, как именно это сделать: Как просматривать и настраивать журналы Linux

Дополнительная информация :

Я исследовал поведение журнала загрузки на двух разных машинах. На компьютере с BIOS на основе UEFI boot.logфайл существует, но на компьютере с устаревшим BIOS его, похоже, не существует вообще. Таким образом, если система установлена ​​в устаревшем режиме BIOS (MBR / msdos), это может быть объяснением того, почему ваш boot.logфайл датирован 2016-04-22, это остаток от Ubuntu 15.10.

Обновленная информация 2016-05-02:

Я продолжал исследовать поведение файла журнала загрузки и заметил, что этот boot.logфайл все еще существует на компьютере с UEFI, но уже несколько дней он пуст. Другой вариант, который я попытался увидеть, что происходит во время процесса загрузки, заключался в установке BootChart , но bootchart.pngон не существовал в /var/logпапке, как ожидалось после перезагрузки системы ... была только пустая /var/log/bootchartпапка, которая также не содержала ожидаемого bootchart.pngфайла.

Обновленная информация 2016-05-04:

Сегодня boot.logфайл, похоже, снова имеет «функциональность», он заполнен частичной информацией из процесса загрузки. Похоже, что это случайно изменяющееся поведение, которое, я думаю, не может быть решено здесь, в Ask Ubuntu, поэтому вы должны подать отчет об ошибке на Launchpad, чтобы решить эту проблему!

Вывод - после одной недели изучения boot.logповедения файлов в Ubuntu 16.04: вам не нужно больше беспокоиться /var/log/boot.logи просто привыкнуть к этому journalctl.

сл-NetBox
источник
не думайте, что что-то пошло не так, в любом случае я хотел бы принять ваш ответ, если бы вы могли добавить предложения о том, как решить мою проблему ...
Жасмин
Попытался вручную настроить демон syslog для генерации файла журнала загрузки в соответствии с руководством. Я добавил # Сохранять загрузочные сообщения также в boot.log local7. * /Var/log/boot.log в мой файл /etc/rsyslog.d/50-default.conf, не повезло, /var/log/boot.log по-прежнему 2016-04-22
жасмины
На моей новой установке Ubuntu 16.04 я также обнаружил, что boot.logфайл находится не в своем обычном месте.
@ParanoidPanda: На обеих упомянутых машинах я выполнил чистую / свежую установку (не обновление) Ubuntu 16.04 LTS - кажется, что прежний способ ведения журнала загрузки больше не поддерживается должным образом. :)
cl-netbox
1
journalctl не показывает то, что я вижу в заставке во время загрузки, и мне это нужно
jasmines