Как прочитать эти записи журнала после неудачной загрузки?
Поскольку вы не указали тип сервиса, systemdпримет значение по умолчанию Type=simple.
В результате systemdпредполагает, что ваша команда ExecStartзапустит фактический процесс обслуживания. Он запустит этот процесс в своей собственной контрольной группе (cgroup )и будет следить за ним. Любые потомки процесса ExecStartбудут членами одной и той же контрольной группы.
Когда процесс ExecStartумирает, systemd предполагает, что это означает, что ваша служба умерла. Поскольку сейчас вы используете сценарий для запуска реальной службы, это предположение будет неверным. В этот момент он убьет все процессы, оставшиеся в контрольной группе, чтобы очистить службу (, эффективно убивая ваш фактический процесс службы ). Затем он пытается перезапустить службу, и цикл повторяется...
Запустив службу косвенно через сценарий, вы фактически изменили тип службы с типа simpleна тип forking, но не сообщили об этом systemd. Но у типа forkingесть некоторый дополнительный устаревший багаж, связанный с ним. Это также затрудняет для systemdмониторинг вашего процесса обслуживания; вам следует избегать этого, если в этом нет крайней необходимости.
В идеале вы должны сохранить начало фактического процесса службы в ExecStart=и указать любые переменные среды в фактическом файле .serviceс параметром Environment=или в отдельном файле, на который ссылается параметр EnvironmentFile=.. Любые дополнительные команды запуска -могут стать опциями ExecStartPre=и/или ExecStartPost=; Таким образом, вы все еще можете сохранить значение по умолчанию Type=simpleи автоматический мониторинг процесса, который он обеспечивает. Вы по-прежнему можете использовать ExecStop=со службой Type=simple, если это необходимо.
Если вы используете Type=forking, systemd по-прежнему будет отслеживать службу через свою контрольную группу. Если служба создает другие процессы, она не будет знать, какой из них является основным процессом службы, и поэтому вам потребуется предоставить по крайней мере опцию PIDFile=, чтобы помочь systemd сначала убить основной процесс службы при остановке службы. оказание услуг,или подходящий ExecStop=, который делает что-то более дружественное к сервису -, чем просто слепое уничтожение процессов.
Если в контрольной группе службы не осталось процессов, systemdвсе равно обнаружит, что служба не удалась. Но с Type=forkingи без PIDFile=основной процесс службы может умереть, а сбой может остаться незамеченным, пока остается хотя бы один из его дочерних процессов.
Когда процесс ExecStop=завершен, если в группе процессов службы остались какие-либо процессы, systemdпредполагает, что это означает, что по какой-то причине не удалось завершить работу, и немедленно использует SIGKILLдля очистки оставшихся процессов. процессы в контрольной группе, если не указано иное, используя различные параметры, перечисленные на справочной странице systemd.kill(5).
Таким образом, если вы используете Type=simple, вам не понадобится PIDFile=и вам не придется беспокоиться о том, что делать, если сбой службы или всей системы оставит вас с устаревшим файлом PID.
Если вы используете Type=forkingи ваша служба использует более одного процесса, вы должны использовать PIDFile=, чтобы systemdмог правильно идентифицировать главный процесс вашей службы, как для целей мониторинга, так и для уничтожения, когда это необходимо.
Если вашей службе требуется более сложный процесс завершения работы, чем просто «отправить SIGTERMсвоему основному/единственному процессу», используйте ExecStop=независимо от опции Type=, но имейте в виду, что она должна обрабатывать все необходимые ожидание/тайм-аут тоже; ожидаемый результат состоит в том, что отключение службы завершается , когда завершается процесс ExecStop=. Если после этого в контрольной группе службы останутся какие-либо процессы, systemdпредположит, что их можно безопасно убить, и немедленно использует SIGKILLдля их очистки.
У вас современный многоядерный процессор -, и ваш дистрибутив использует systemd. В результате во время загрузки многие вещи будут происходить параллельно, иногда без фиксированного порядка. Некоторые из сообщений журнала могут немного отличаться друг от друга, если они используют разные маршруты (собственное systemdведение журнала по сравнению с подсистемой аудита ядра и системными вызовами системного журнала ).
Я пройдусь по сообщениям в основном в -последовательном порядке, но сгруппирую некоторые похожие сообщения вместе.
Jan 22 01:42:53 hostname kernel: Linux version 5.10.9-arch1-1 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #1 SMP PREEMPT Tue, 19 Jan 2021 22:06:06 +0000
Jan 22 01:42:53 hostname kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=d825234f-4397-494f-9c61-e719a008ecbd rw loglevel=3 quiet
Обычно это самые первые строки, которые ядро Linux выводит сразу после начала выполнения. В этот момент системные часы просто используют значение времени, которое инициализировала системная прошивка, которое обычно исходит от микросхемы часов с батарейным питанием -. Обратите внимание на параметры ядра loglevel=3 quiet:, они заглушают многие сообщения о ранней загрузке, поэтому после этого и до следующих сообщений может произойти многое.
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input15
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input16
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input17
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input18
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input19
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input20
Jan 22 01:38:09 hostname kernel: input: HDA NVidia HDMI/DP,pcm=12 as /devices/pci0000:00/0000:00:02.1/0000:01:00.1/sound/card1/input21
Jan 22 01:38:09 hostname kernel: input: HD-Audio Generic Front Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input22
Jan 22 01:38:09 hostname kernel: input: HD-Audio Generic Rear Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input23
Jan 22 01:38:09 hostname kernel: input: HD-Audio Generic Line as /devices/pci0000:00/0000:00:14.2/sound/card0/input24
Jan 22 01:38:09 hostname kernel: input: HD-Audio Generic Line Out as /devices/pci0000:00/0000:00:14.2/sound/card0/input25
Jan 22 01:38:09 hostname kernel: input: HD-Audio Generic Front Headphone as /devices/pci0000:00/0000:00:14.2/sound/card0/input26
Эти сообщения исходят от входной подсистемы, регистрирующей цепи обнаружения штекеров на различных аудиоразъемах в качестве входов. Это означает, что на данный момент звуковые драйверы уже загружены. Звуковые чипы обычно не считаются «необходимым оборудованием», поэтому их драйверы обычно не встраиваются в ядро и даже не всегда включаются в initramfs, так что на данный момент мы, вероятно, немного продвинулись в процессе загрузки.
Возможно, процесс загрузки уже активировал сетевой интерфейс (s )и получил более точную информацию о времени с NTP-сервера, что может объяснить очевидный скачок времени назад. Или процесс загрузки может принять время последней операции записи на диск как наилучшее предположение о текущем времени, если часы с резервным питанием от батареи -недоступны и серверы NTP еще не доступны.
Jan 22 01:38:09 hostname audit[425]: NETFILTER_CFG table=filter family=10 entries=144 op=xt_replace pid=425 comm="ip6tables-resto"
Jan 22 01:38:09 hostname audit[426]: NETFILTER_CFG table=filter family=10 entries=160 op=xt_replace pid=426 comm="ip6tables-resto"
Jan 22 01:38:09 hostname audit[435]: NETFILTER_CFG table=filter family=10 entries=168 op=xt_replace pid=435 comm="ip6tables-resto"
Что-то (, вероятно,ip6tables-restore)вызывает добавление правил сетевого фильтра IPv6.
Jan 22 01:38:09 hostname kernel: EDAC amd64: F15h detected (node 0).
Jan 22 01:38:09 hostname kernel: EDAC amd64: Error: F1 not found: device 0x1601 (broken BIOS?)
Эти сообщения исходят от подсистемы (обнаружения и исправления ошибок )EDAC. Это в основном полезно в системах с ошибкой ECC -, исправляющей только память (, то есть на серверах и, возможно, рабочих станциях -высокого класса ). Похоже, что ваш процессор обладает необходимыми функциями для работы с памятью ECC, но микропрограмма вашей системы, по-видимому, не содержит необходимой информации для подсистемы EDAC для сопоставления ошибок памяти/шины с физическим компонентом (, например. слот модуля памяти ). Возможно, ваша материнская плата не способна использовать память ECC? Если это так, то подсистема EDAC может оказаться для вас бесполезной, и вы можете занести модули EDAC в черный список, чтобы вообще не загружать их.
Jan 22 01:38:09 hostname systemd-udevd[258]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99.
Jan 22 01:38:10 hostname systemd-udevd[267]: controlC1: Process '/usr/bin/alsactl restore 1' failed with exit code 99.
По какой-то причине попытки восстановить настройки громкости звуковой карты не увенчались успехом как для встроенного звукового чипа материнской платы, так и для разъемов HDMI/DP графического процессора. Возможно, потому что alsactl storeникогда не использовался для постоянного сохранения текущих настроек? Это может быть важно только в том случае, если вы используете необработанный ALSA и/или текстовый режим :, большинство сред рабочего стола с графическим интерфейсом и/или Pulseaudio в любом случае обычно переопределяют настройки громкости ALSA пользовательскими -настройками.
Jan 22 01:38:09 hostname systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Jan 22 01:38:09 hostname systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
Jan 22 01:38:09 hostname systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped.
Jan 22 01:38:09 hostname systemd[1]: Condition check resulted in Repartition Root Disk being skipped.
Jan 22 01:38:09 hostname systemd[1]: Condition check resulted in Create System Users being skipped.
systemdпропускает некоторые элементы условной загрузки, так как необходимые условия не выполнены.
Jan 22 01:38:10 hostname kernel: nvidia: module license 'NVIDIA' taints kernel.
Jan 22 01:38:10 hostname kernel: Disabling lock debugging due to kernel taint
Jan 22 01:38:10 hostname kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 237
Jan 22 01:38:10 hostname kernel:
Jan 22 01:38:10 hostname kernel: nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
Jan 22 01:38:10 hostname kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 460.32.03 Sun Dec 27 19:00:34 UTC 2020
Загружается проприетарный драйвер графического процессора NVIDIA.
Jan 22 01:38:10 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-random-seed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Похоже, что корневая файловая система смонтирована, а «настоящий» запуск systemd -подтверждается подсистемой аудита. До этого момента процесс загрузки обрабатывался «мини -systemd» внутри initramfs. Это может объяснить, почему некоторые сообщения кажутся повторяющимися :initramfs mini -systemd выполнила эти проверки один раз, а теперь настоящая systemd делает их снова.
Jan 22 01:38:10 hostname kernel: random: crng init done
Jan 22 01:38:10 hostname kernel: random: 7 urandom warning(s) missed due to ratelimiting
Jan 22 01:38:10 hostname systemd[1]: Finished Load/Save Random Seed.
systemdвосстановил случайное начальное число из последнего запуска или упорядоченного завершения работы.
Jan 22 01:38:10 hostname kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 460.32.03 Sun Dec 27 18:51:11 UTC 2020
Jan 22 01:38:10 hostname kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Jan 22 01:38:10 hostname kernel: [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 0
Запуск дополнительных компонентов проприетарного драйвера графического процессора NVIDIA.
Jan 22 01:38:10 hostname systemd[1]: Created slice system-systemd\x2dbacklight.slice.
Jan 22 01:38:10 hostname systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
Jan 22 01:38:10 hostname systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:acpi_video0.
Jan 22 01:38:10 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@backlight:acpi_video0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? termi>
Таблицы ACPI встроенного ПО включают интерфейс управления подсветкой, а systemdзапускает службу, которая запоминает текущие настройки подсветки от одной загрузки к другой.
Jan 22 01:38:18 hostname kernel: ata2: softreset failed (1st FIS failed)
Jan 22 01:38:28 hostname kernel: ata2: softreset failed (1st FIS failed)
Это указывает на проблемы со вторым устройством SATA. Ваш второй фрагмент, кажется, содержит больше информации об этом.
Из второго фрагмента:
Jan 22 01:38:08 hostname kernel: ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20200925/tbfadt-615)
Прошивка вашей системы ACPI содержит неполную информацию об управлении питанием. Обновление BIOS может исправить это, но поскольку это всего лишь предупреждение, ядро может смириться с проблемой.
Jan 22 01:38:08 hostname kernel: ata2.00: exception Emask 0x0 SAct 0x30000 SErr 0x0 action 0x6
Jan 22 01:38:08 hostname kernel: ata2.00: irq_stat 0x40000008
Jan 22 01:38:08 hostname kernel: ata2.00: failed command: READ FPDMA QUEUED
Jan 22 01:38:08 hostname kernel: ata2.00: cmd 60/78:80:88:00:00/00:00:00:00:00/40 tag 16 ncq dma 61440 in
res 43/84:78:f0:00:00/00:00:00:00:00/00 Emask 0x410 (ATA bus error) <F>
Jan 22 01:38:08 hostname kernel: ata2.00: status: { DRDY SENSE ERR }
Jan 22 01:38:08 hostname kernel: ata2.00: error: { ICRC ABRT }
Jan 22 01:38:08 hostname kernel: ata2: hard resetting link
Jan 22 01:38:08 hostname kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 22 01:38:08 hostname kernel: ata2.00: NCQ Send/Recv Log not supported
Jan 22 01:38:08 hostname kernel: ata2.00: NCQ Send/Recv Log not supported
Jan 22 01:38:08 hostname kernel: ata2.00: configured for UDMA/133
Jan 22 01:38:08 hostname kernel: sd 1:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=1s
Jan 22 01:38:08 hostname kernel: sd 1:0:0:0: [sdb] tag#16 Sense Key : Aborted Command [current]
Jan 22 01:38:08 hostname kernel: sd 1:0:0:0: [sdb] tag#16 Add. Sense: Scsi parity error
Jan 22 01:38:08 hostname kernel: sd 1:0:0:0: [sdb] tag#16 CDB: Read(10) 28 00 00 00 00 88 00 00 78 00
Jan 22 01:38:08 hostname kernel: blk_update_request: I/O error, dev sdb, sector 136 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Это указывает на ошибку передачи данных с вашего /dev/sdbдиска. Это может быть вызвано плохим кабелем или разъемом SATA, поэтому сначала попробуйте переместить диск на другой порт SATA или сначала заменить кабель. Если эти вещи не помогут, возможно, потребуется заменить диск. Если ошибка появляется и исчезает, сделайте дополнительную резервную копию этого диска как можно скорее.