Reboot-Grund?

[Mickey Cohen]

Hallo,

kann mir irgendwer von euch aus dem nachfolgenden journalctl-log-Ausschnitt sagen, warum mein rechner um

Jun 04 16:25:22 Uhr

rebooted hat?

Bei bedarf kann ich noch weitere Einträge nachreichen, aber ich glaube alles was davor oder danach passiert ist, ist nicht mehr wirklich relevant.

System: Fedora 32, KDE Plasma 5.18

Vielen Dank!

Jun 04 15:01:01 ryzen1600-fed CROND[2583]: (root) CMD (run-parts /etc/cron.hourly)
Jun 04 15:01:01 ryzen1600-fed run-parts[2586]: (/etc/cron.hourly) starting 0anacron
Jun 04 15:01:01 ryzen1600-fed anacron[2592]: Anacron started on 2020-06-04
Jun 04 15:01:01 ryzen1600-fed anacron[2592]: Will run job `cron.daily' in 24 min.
Jun 04 15:01:01 ryzen1600-fed anacron[2592]: Jobs will be executed sequentially
Jun 04 15:01:01 ryzen1600-fed run-parts[2594]: (/etc/cron.hourly) finished 0anacron
Jun 04 15:25:01 ryzen1600-fed anacron[2592]: Job `cron.daily' started
Jun 04 15:25:01 ryzen1600-fed anacron[2592]: Job `cron.daily' terminated
Jun 04 15:25:01 ryzen1600-fed anacron[2592]: Normal exit (1 job run)
Jun 04 15:27:02 ryzen1600-fed cupsd[974]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
Jun 04 15:39:35 ryzen1600-fed systemd[1]: Starting dnf makecache...
Jun 04 15:39:35 ryzen1600-fed dnf[2655]: Metadata cache refreshed recently.
Jun 04 15:39:35 ryzen1600-fed systemd[1]: dnf-makecache.service: Succeeded.
Jun 04 15:39:35 ryzen1600-fed systemd[1]: Finished dnf makecache.
Jun 04 15:39:35 ryzen1600-fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-make>
Jun 04 15:39:35 ryzen1600-fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makec>
Jun 04 16:01:01 ryzen1600-fed CROND[2692]: (root) CMD (run-parts /etc/cron.hourly)
Jun 04 16:01:01 ryzen1600-fed run-parts[2695]: (/etc/cron.hourly) starting 0anacron
Jun 04 16:01:01 ryzen1600-fed run-parts[2701]: (/etc/cron.hourly) finished 0anacron
Jun 04 16:25:22 ryzen1600-fed cupsd[974]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
-- Reboot --
Jun 04 20:24:05 localhost.localdomain kernel: Linux version 5.6.15-300.fc32.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 10.1.1 >
Jun 04 20:24:05 localhost.localdomain kernel: Command line: BOOT_IMAGE=(hd1,gpt3)/boot/vmlinuz-5.6.15-300.fc32.x86_64 root=UUID=6878515f-40d0-4fd4-a>
Jun 04 20:24:05 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jun 04 20:24:05 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jun 04 20:24:05 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jun 04 20:24:05 localhost.localdomain kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Jun 04 20:24:05 localhost.localdomain kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.

 

[En3rg1eR1egel]

mit den nichtvorhandenen informationen ?
nein

/var/log/syslog
bzw
/var/log/messages

da mal nachschauen

 

[Mickey Cohen]

ok, war das jetzt eine kritik an mir, dass ich mehr informationen liefern soll? wenn ja, würde ich das gerne nachholen, ich bräuchte nur einen hinweis, welche infos ich noch liefern soll...danke


edit:
/var/log/syslog existiert nicht bei Fedora/RHEL Distris und in var/log/messages steht nur folgendes (Auszugsweise):

Jun  4 15:39:35 ryzen1600-fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun  4 15:39:35 ryzen1600-fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun  4 16:25:22 ryzen1600-fed cupsd[974]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
Jun  4 15:39:35 ryzen1600-fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun  4 16:25:22 ryzen1600-fed cupsd[974]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
Jun  4 20:24:05 ryzen1600-fed kernel: Linux version 5.6.15-300.fc32.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)) #1 SMP Fri May 29 14:23:59 UTC 2020

da steht also auch nicht mehr drinnen.

Laut meinen Recherchen soll wohl die journalctl-Ausgabe die umfangreichste Log-Ausgabe sein?
Es muss doch irgendwo noch nen vernünftigen error log geben?

 

[JpG]

Den Hinweis hat er dir doch gegeben.

/var/log/syslog
bzw
/var/log/messages

da mal nachschauen

 

[Mickey Cohen]

er hat seine antwort noch editiert ist schon geschehen

 

[BFF]

Rennt das Teil auf harter Hardware oder ist das eine VM?

Da "fehlen" ca. 4h in dem Log.
Fuer reboot etwas lange. Standby oder Sleep eingestellt?

 

[Mickey Cohen]

Rennt das Teil auf harter Hardware oder ist das eine VM?

Da "fehlen" ca. 4h in dem Log.
Fuer reboot etwas lange. Standby oder Sleep eingestellt?

ne, das ist ne "echte" maschine, keine virtuelle.

das mit der langen zeit nach dem reboot erklärt sich damit, dass der rechner @ default ins parallel installierte windows10 bootet.

standby und sleep sind deaktiviert, aber der bildschirm wird nach 30min idle abgeschaltet.

ich vermute ja irgendwas mit dem grafiktreiber...ist eine radeon r9 380 und treiber ist der offene amdgpu (also der standardtreiber).
gibts da noch irgendeinen aussagekräftigeren Xorg log oder so?
oder irgendwas, das mir hardware- und treiberfehler anzeigt?

oder auch für die zukunft. denn das wird nicht das letzte mal gewesen sein...

 

[snaxilian]

Prüfe die Ausgabe von cat /proc/sys/kernel/panic. Falls dies eine 1 liefert > Kernel Panic, falls 0 hast du das zumindest ausgeschlossen.
Gibt es noch die /var/log/messages?Was sagt diese so ab 16 Uhr?
Was sagt die Ausgabe von last -5 -x? Das gibt die letzten 5 Änderungen der Runlevel als auch reboot und shutdown Events an und ob diese von einem User oder dem System ausgelöst wurde.

 

[lokon]

gibts da noch irgendeinen aussagekräftigeren Xorg log oder so?
oder irgendwas, das mir hardware- und treiberfehler anzeigt?

.local/share/xorg/

Die Hardware/Treiberfehler sind als oops eigentlich im Kernel-Log und auch in journalctl enthalten
journalctl --list-boots , journalctl -k

Für "aussagekräftige Logs" können Bootparameter des Kernels geändert werden oder als Parameter beim Kernel-Treibermodul (oder Umgebungsvariable), Logs an Netzwerkserver (oder serielle Konsole) via netconsole verschickt werden.
Außerdem gibt es ramoops / pstore - hier oder hier - damit wird Speicher reserviert, der die Kernel-OOPS enthält - hier dürfte aber kein Windows per default gebootet werden.
Nicht alle Fehler müssen in Logs erscheinen - bei Netzteilfehlern durch Unterspannung oder Spannungsschutz durch ESD / Kurzschluss fehlen wahrscheinlich solche Einträge.

Für verschiedene Treiber gibt es bei Linux teilweise Vorschriften / Ratgeber, was bei Bugs zu tun ist.
Alles sehr umfangreich und komplex - zB https://01.org/linuxgraphics/documentation/how-report-bugs

 

[Mickey Cohen]

Prüfe die Ausgabe von cat /proc/sys/kernel/panic. Falls dies eine 1 liefert > Kernel Panic, falls 0 hast du das zumindest ausgeschlossen.
Gibt es noch die /var/log/messages?Was sagt diese so ab 16 Uhr?
Was sagt die Ausgabe von last -5 -x? Das gibt die letzten 5 Änderungen der Runlevel als auch reboot und shutdown Events an und ob diese von einem User oder dem System ausgelöst wurde.

cat /proc/sys/kernel/panic liefert 0

/var/log/messages gibt es noch, nach meinem Verständnis sollte theoretisch aber alles, was da drin steht seit systemd jedenfalls auch im journalctl log stehen. so scheint es auch tatsächlich zu sein, wenn ich die beiden ausgaben vergleiche, siehe post #1 und #3

last -5 -x hat sich erledigt, da ich mittlerweile mehrmals neu gestartet habe etc...
edit: bin gerade draufgekommen, dass man die -5 ja auch durch ne höhere zahl ersetzen kann

reboot   system boot  5.6.15-300.fc32. Thu Jun  4 20:26 - 19:01  (-1:24)
wayne    pts/1        :0               Thu Jun  4 18:24 - 18:24  (00:00)
wayne    pts/0        :0               Thu Jun  4 18:24 - crash  (02:01)
wayne    tty1         :0               Thu Jun  4 18:24 - crash  (02:01)
runlevel (to lvl 5)   5.6.15-300.fc32. Thu Jun  4 18:24 - 18:26  (00:01)
reboot   system boot  5.6.15-300.fc32. Thu Jun  4 20:24 - 19:01  (-1:22)
wayne    pts/1        :0               Thu Jun  4 14:28 - 14:29  (00:00)
wayne    pts/0        :0               Thu Jun  4 14:28 - crash  (05:55)
wayne    tty1         :0               Thu Jun  4 14:28 - crash  (05:55)
runlevel (to lvl 5)   5.6.15-300.fc32. Thu Jun  4 14:28 - 18:24  (03:55)
reboot   system boot  5.6.15-300.fc32. Thu Jun  4 16:28 - 19:01  (02:33)
shutdown system down  5.6.15-300.fc32. Thu Jun  4 14:28 - 16:28  (02:00)
wayne    pts/1        :0               Thu Jun  4 14:21 - 14:27  (00:05)

blöd ist irgendwie auch, dass der logger immer verschiedene zeitzonen benutzt, wohl je nachdem ob die lokale zeitzoneneinstellung schon geladen ist oder nicht (vermute ich). demnach kann sich das jeweils geloggte ereignis (jetzt zur sommerzeit) mal um zwei stunden früher oder später (ich komm da immer durcheinander) ereignet haben, als im log steht.

der tatsächliche fragliche reboot müsste aber der um 16:28 gewesen sein. also ein system reboot...

macht Fedora / KDE @ default automatische reboots bspw. nach nem auto-update (wie windows)? ich meine doch ehe rnicht, oder?

 

[Ratz_Fatz]

Bisher hat Fedora bei mir nach Updates keine selbständigen Neustarts bei mir gemacht. Probleme(KernelPanics...) gab es bei mir vor allem mit AMD Ryzen APUs, teilweise sehr eigenartiges Verhalten.

Du kannst mal nachschauen ob die folgenden Eingaben etwas mehr ausgeben:

sudo -i
dmesg -x -l crit,err,warn
journalctl -p err..alert

 

[Mickey Cohen]

Bisher hat Fedora bei mir nach Updates keine selbständigen Neustarts bei mir gemacht. Probleme(KernelPanics...) gab es bei mir vor allem mit AMD Ryzen APUs, teilweise sehr eigenartiges Verhalten.

Du kannst mal nachschauen ob die folgenden Eingaben etwas mehr ausgeben:

sudo -i
dmesg -x -l crit,err,warn
journalctl -p err..alert

ok, danke!

dmesg -x -l crit,err,warn liefert:

Spoiler: dmesg

# dmesg -x -l crit,err,warn
kern  :warn  : [    0.000000] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20200110/tbfadt-615)
kern  :warn  : [    0.714019]  PPR NX GT IA GA PC GA_vAPIC
kern  :warn  : [    0.725258] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725357] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725417] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725468] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725527] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725602] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725664] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725730] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725791] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725883] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.725968] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.726043] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern  :warn  : [    0.786080] usb: port power management may be unreliable
kern  :warn  : [    1.199790] ata1.00: supports DRM functions and may not be fully accessible
kern  :warn  : [    1.200379] ata1.00: supports DRM functions and may not be fully accessible
kern  :warn  : [    1.671659] ata2.00: supports DRM functions and may not be fully accessible
kern  :warn  : [    1.695596] ata2.00: supports DRM functions and may not be fully accessible
kern  :warn  : [    3.595254] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
kern  :warn  : [    3.595278] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
kern  :warn  : [    3.595302] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
kern  :warn  : [    5.421191] kauditd_printk_skb: 34 callbacks suppressed
syslog:warn  : [    5.997508] systemd-journald[648]: File /run/log/journal/dc935d32a6ff42398de9a01330adb047/system.journal corrupted or uncleanly shut down, renaming and replacing.
syslog:warn  : [    6.027051] systemd-journald[648]: File /var/log/journal/dc935d32a6ff42398de9a01330adb047/system.journal corrupted or uncleanly shut down, renaming and replacing.
kern  :warn  : [   10.435468] kauditd_printk_skb: 35 callbacks suppressed

journalctl -p err..alert liefert zu der zeit, als der reboot stattfand, keine einträge...



mittlerweile hat sich wieder ein reboot ereignet.

Spoiler: journalctl

Jun 07 17:55:39 ryzen1600-fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makec>
Jun 07 17:55:39 ryzen1600-fed systemd[1]: dnf-makecache.service: Consumed 1.756s CPU time.
Jun 07 18:01:01 ryzen1600-fed CROND[4400]: (root) CMD (run-parts /etc/cron.hourly)
Jun 07 18:01:01 ryzen1600-fed run-parts[4403]: (/etc/cron.hourly) starting 0anacron
Jun 07 18:01:01 ryzen1600-fed run-parts[4409]: (/etc/cron.hourly) finished 0anacron
Jun 07 18:19:29 ryzen1600-fed cupsd[968]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
Jun 07 18:36:08 ryzen1600-fed nextcloud[4457]: Icon theme "Materia-Manjaro-Breeze-Dark" not found.
Jun 07 18:36:09 ryzen1600-fed kwin_x11[1577]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 42036, resource id: 88080395, major co>
Jun 07 18:56:33 ryzen1600-fed systemd[1]: Starting dnf makecache...
Jun 07 18:56:33 ryzen1600-fed dnf[4512]: Metadata cache refreshed recently.
Jun 07 18:56:33 ryzen1600-fed systemd[1]: dnf-makecache.service: Succeeded.
Jun 07 18:56:33 ryzen1600-fed systemd[1]: Finished dnf makecache.
Jun 07 18:56:33 ryzen1600-fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-make>
Jun 07 18:56:33 ryzen1600-fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makec>
Jun 07 19:01:01 ryzen1600-fed CROND[4523]: (root) CMD (run-parts /etc/cron.hourly)
Jun 07 19:01:01 ryzen1600-fed run-parts[4526]: (/etc/cron.hourly) starting 0anacron
Jun 07 19:01:01 ryzen1600-fed run-parts[4532]: (/etc/cron.hourly) finished 0anacron
Jun 07 19:17:49 ryzen1600-fed cupsd[968]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok
-- Reboot --
Jun 07 22:52:12 localhost.localdomain kernel: Linux version 5.6.15-300.fc32.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 10.1.1 >

wie beim letzten mal war die unmittelbar letzte meldung vor dem reboot:
Jun 07 19:17:49 ryzen1600-fed cupsd[968]: REQUEST localhost - - "POST / HTTP/1.1" 200 184 Renew-Subscription successful-ok

ich vermute also einen zusammenhang damit.
allerdings wurde die meldung auch um 18:19:29 ohne anschließendem reboot aufgeführt.

mal schaun, was das ist.

 

[En3rg1eR1egel]

ich vermute also einen zusammenhang damit.

unrealistisch,
aber lässt sich ja einfach testen.

dienst stoppen , fertig

 

[usbstick]

@Mickey Cohen hast Du journalctl als root oder per sudo ausgeführt? Beim Ausführen als User bekommt man nicht die komplette Detailtiefe.

 

[Ratz_Fatz]

@Mickey Cohen
Vielleicht hilft es Fedora mit SecureBoot und KernelLockdown(Info dazu bei zdnet) zu betreiben, du kannst das ja mal testen. Ansonsten ist es vielleicht ein Hardware Problem? Netzteil, Ram... am besten mal die Hardware hier reinschreiben.

Fedora speichert doch eigentlich einiges mit "ABRT", du kannst dort mal nachschauen.

Zeig mal bitte die folgende Ausgabe(Tainted kernels und weitere Erklärung):

for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done

Du kannst dem Grub zum testen die Parameter hinzufügen.

security_lockdown_lsm_early lockdown=confidentiality acpi=strict pci=nocrs iommu=soft

 

[muce]

kann mir irgendwer von euch aus dem nachfolgenden journalctl-log-Ausschnitt sagen, warum mein rechner
rebooted hat?

Was ist der Zweck dieser Untersuchung? Nur Neugier, oder Aufdecken von Hardware-Problemen, oder Aufdecken von Konfigurationsfehlern, oder was?

Das weitere Vorgehen hängt stark von der Antwort darauf ab.