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

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

Использовать journalctl

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

 journalctl -b0 SYSLOG_PID=1 
  • -b0 показывает сообщения от текущей загрузки, -b1 от предыдущей загрузки и т. д. Без опции -b , journalctl покажет сообщения с начала журнала.
  • SYSLOG_PID фильтрует сообщения от PID 1, aka 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 по умолчанию journalctl журналы в пейджере, поэтому вам не нужно 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 

Связанный:

  • Как отображать сообщения журнала из предыдущих загрузок в CentOS 7?

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

Я просматривал некоторые сообщения об ошибках и заметил в этом: 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.