Sporadischer Crash/Reboot

[H-Cl]

Hallo zusammen,

seit ein paar Tagen habe ich sporadische Crashes, der Rechner startet unvermittelt neu, wie nach Netz aus/ein.

Ein Zusammenhang mit irgendwelchen Programmen/Aktionen ist nicht zu erkennen, deshalb tippe ich auf ein HW Problem.
Die Temperaturen von CPU und Mainboard sind im grünen Bereich (62°C bzw. 32°C)
Da mein Netzteil schon 3 Mainboards "überlebt" hat wäre, das mein erster Ansatzpunkt.
Wie kann ich dem Fehler auf den Grund gehen?

Viele Grüße

H-Cl

[Teriarch]

Hallo H-Cl,

es kann sich auch um ein Speicherproblem handeln. Wenn
nicht schon vorhanden, kannst Du mit

$ sudo apt-get install memtest86+

ein Testprogramm installieren und im Grub Menu (vor dem
Booten des Betriebssystems) dieses aufrufen. Zumindest lässt
sich damit ein Fehler ausschließen.

Im selben Menu besteht auch die Möglichkeit durch Hinzufügen
von "emergency" am Ende der Grub Bootzeile in den Single User
Mode zu booten und den Rechner für ein paar Stunden stehen zu lassen.
Falls er überlebt, kann es sich um ein Hitze Problem im Chipsatz handeln.

Es ist schwer, ohne weitere Infos dem Problem zielgerecht auf den
Grund zu gehen.

[H-Cl]

Werde ich heute Nacht mal probieren.
Gibt es irgendwelche Logdateien, in denen man vielleicht hilfreiche Informationen finden könnte?

[Teriarch]

> Gibt es irgendwelche Logdateien, in denen man vielleicht hilfreiche Informationen finden könnte?

Das kommt darauf an. Falls der "Absturz" durch Software verursacht wurde, kann ein Eintrag für
diesen Zeitpunkt in /var/log/kern.log vorhanden sein. Falls ein HW Fehler die Ursache ist, gibt es
keinen solchen, denn der Prozessor hat bei Stromausfall oder einem Reset keine Möglichkeit mehr,
Code auszuführen, folglich wird auch nichts mehr in logfiles geschrieben.

Ein Hinweis auf solch einen "Sudden Death" kann der nächste Reboot geben. Wenn Du die
Kernel Messages einzeln verfolgst, wird bei einem Hard Reset beim nächsten Reboot das Filesystem
vor dem Rootmount überprüft, und das zeigen Dir auch die Nachrichten an.

Handelt es sich um einen Laptop oder Desktop? Schaltet sich der Rechner nach dem Vorfall aus oder
bootet er neu? Noch eine Idee: Hast Du in den kde Einstellungen (vielleicht unwissentlich) einen sleep,
suspend  oder hibernate mode nach einer gewissen Zeit der Inaktivität gesetzt?

[H-Cl]

Der Rechner bootet neu, es wirkt wie ein kurzer Stromausfall.

Die (versehentliche) Aktivierung einer Energiesparfunktionen halte ich für unwahrscheinlich.
Es wird eine neue leere Sitzung gestartet.

Logdateien gibt es in /var/log/ nicht, ich müsste wohl eher journalctl bemühen, wobei ich nicht weiß wie und nach was ich da suchen sollte.


Es handelt sich um einen alten Desktop, der immer wieder hochgerüstet wird.
Mainboard, CPU, RAM, SSD (M2) sind ca. 3,5 Jahre alt, also eigentlich noch in der unkritischen Phase der Badewannenkurve.
Das Netzteil hat schon mehr als 10 Jahre auf dem Buckel, die sonstigen aktiven Komponenten liegen irgendwo dazwischen.

[Teriarch]

> Logdateien gibt es in /var/log/ nicht,

Das ist seltsam, läuft rsyslogd?

$ ps xa|grep rsyslogd

Und was steht in /etc/rsyslog.conf?

Ist das Debianpaket rsyslog installiert?

[H-Cl]

memtest ist fehlerfrei durchgelaufen

In /var/log gibt es eine README mit folgendem Inhalt

Code Select Expand


You are looking for the traditional text log files in /var/log, and they are
gone?

Here's an explanation on what's going on:

You are running a systemd-based OS where traditional syslog has been replaced
with the Journal. The journal stores the same (and more) information as classic
syslog. To make use of the journal and access the collected log data simply
invoke "journalctl", which will output the logs in the identical text-based
format the syslog files in /var/log used to be. For further details, please
refer to journalctl(1).

Alternatively, consider installing one of the traditional syslog
implementations available for your distribution, which will generate the
classic log files for you. Syslog implementations such as syslog-ng or rsyslog
may be installed side-by-side with the journal and will continue to function
the way they always did.

Thank you!

Further reading:
        man:journalctl(1)
        man:systemd-journald.service(8)
        man:journald.conf(5)
        https://0pointer.de/blog/projects/the-journal.html


rsyslog war nicht installiert, habe ich jetzt nachgeholt.

Inhalt von /etc/rsyslog.conf

Code Select Expand


# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html


#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")


###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf


###############
#### RULES ####
###############

#
# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.* /var/log/auth.log
cron.* -/var/log/cron.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*



[hendrikL]

nun, journalctl könnte auch Aufschluss geben.
Ich meine mich zu entsinnen, daß im Handbuch einiges dazu steht.

[H-Cl]

Jetzt stellt sich noch die Frage, wonach ich suchen soll.

Um nicht mit Megabytes erschlagen zu werden, habe mal folgendes probiert

Code Select Expand


journalctl -b -1 -p err


Das liefert zwar ein paar Fehlermeldungen, aber ich vermute, dass die nichts mit dem Absturz zu tun haben

Code Select Expand


un 08 14:08:59 desktop-holger systemd-udevd[500]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring.
Jun 08 14:08:59 desktop-holger systemd-udevd[500]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
                                               
                                               
                                                JSON blob:
                                                {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Failed to load user configuration. Falling back to full stock configuration.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
                                               
                                               
                                                JSON blob:
                                                {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
                                               
                                               
                                                JSON blob:
                                                {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Datei oder Verzeichnis nicht gefunden
                                               
                                               
                                                JSON blob:
                                                {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -140}}}, {"add": {"chain">
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Failed to load full stock configuration. This likely indicates a system level issue, e.g. the firewall backend (nftables, iptables) is broken. All hope is lost. Exiting.
Jun 08 14:09:02 desktop-holger firewalld[1272]: ERROR: Raising SystemExit in run_server
Jun 08 14:09:02 desktop-holger blkmapd[1694]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:02 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 14:09:05 desktop-holger obexd[5304]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolution-source-registry.service not found.
Jun 08 14:09:05 desktop-holger obexd[5304]: Unable to acquire registry: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources5: Unit evolution-source-registry.service not found.
Jun 08 14:12:12 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 19:21:15 desktop-holger kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 8-...D } 22 jiffies s: 1961 root: 0x100/.
Jun 08 19:21:15 desktop-holger kernel: rcu: blocking rcu_node structures (internal RCU debug):
Jun 08 21:17:22 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 21:17:32 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 21:26:52 desktop-holger rtkit-daemon[1932]: Failed to make ourselves RT: Operation not permitted
Jun 08 22:23:47 desktop-holger blkmapd[1694]: exit on signal(15)



[Teriarch]

Und der Vollständigkeit halber:
Absturz im emergency mode?
Wurde nach dem Reboot ein FS Check erzwungen?

[hendrikL]

 Welche Aufzeichnungen hat das journal kurz vor dem Crash gemacht?

Dann sehe ich irgendwas mit obex, Bluetooth?
Ist irgendwas externes wärend des Crashes angeschlossen?

Es gibt die Möglichkeit das Journal recursiv ausgeben zu lassen, -r oder -R, kann gerade nicht nach schauen.

Man kann auch genaue Zeitabschnitte ausgeben lassen.

Kernel Meldungen, Hardware Meldungen usw. suchen.

Anders Netzteil vielleicht testen?

[H-Cl]

Heute morgen gab es wieder eine Crash.
Hier sind die Logdaten vor dem Crash und dem anschließenden Reboot.

Unmittelbar vorm Crash kann ich nichts erkennen. Zu den drkonqi Meldungen gibt es viele Treffer, einen Hinweis auf einen Crash kann ich aber nicht finden.

Nach welchen Begriffen soll ich konkret suchen?

Die einzigen externen USB-Geräte sind der USB Hub vom Monitor, an dem die Empfänger für Maus/Tastatur und Webcam angeschlossen sind und ein USB-Hub, an den aktuell nichts angeschlossen ist.
BT hatte ich mal aktiviert, da der USB-Adapter nicht funktioniert, ist der nicht angeschlossen.
Das letzte Update ist (wegen akutem Zeitmangel) schon etwas länger her, also sehe ich auch hier keinen Zusammenhang.

Wackelkontakte/Kurzschlüsse (z.B. Resettaster halte ich für unwahrscheinlich, da bei den Crashes definitiv nichts berührt wurde. Trotzdem werde ich später mal das Gehäuse öffnen, um alle Steckverbinder zu prüfen.

Ein Netzteil zum testen habe ich nicht. Ich wollte, bevor ich nur auf Verdacht ein neues bestelle, erst mal der Ursache auf den Grund gehen.
Was wäre da empfehlenswert?
Es soll leise sein und eine hohe Effizienz haben.
Die Hocheffizienten scheint es nur für Cryptomining-Heizungen >500W zu geben, wodurch diese in meinem System (meist ~30W, max 80W) auch wieder ineffizient werden.

Und dann noch eine ganz OT Frage, kann man inzwischen wieder ohne Bedenken beim ehemals insolventen Hamburger Kistenschieber bestellen?


Update:

Im Gehäuse gibt es keine Auffälligkeiten. Die Verbindungen wirken stabil, die Lüfter laufen und es gab deutlich weniger Staub als befürchtet.

[hendrikL]

Vielleicht mal die Ausgabe etwas eingrenzen.

Code Select Expand

$ journalctl --since "2025-06-10 07:56:00" --until "2025-06-10 07:58:33"

Gegebenenfalls, die Uhrzeit anpassen, "--since ...".

Interessant wären die Meldungen kurz vor dem Absturz, "drkonqi-coredump ......" bis zum boot.

Edit: die Zeit kurz vor dem coredump!

Ps.: Fixed Typo 2015 =! 2025

[H-Cl]

Genau so hab ich das gemacht, ~30 s vorm Crash und ~2 Minuten danach.

Code Select Expand


journalctl --since="2025-06-10 07:57" --until="2025-06-10 08:02"  > Crash.log


Auch wenn ich eine Anfangszeit vorm Systemstart eingebe, gibt es keine verwertbaren zusätzlichen Informationen. Da die Minuten vorher genauso aussehen wie die letzten 30 Sekunden, habe ich diese weggelassen.
Nach Abschluss Hochlaufs (07:54:53), gibt es nur noch eine Anhäufung der folgenden 3 Einträge:

Code Select Expand


Jun 10 07:54:27 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:54:27 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later.
Jun 10 07:54:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 1 users.


Hier die Einträge unmittelbar vor und nach dem Crash/Reboot

Code Select Expand


Jun 10 07:58:23 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket: Unit needs to be started because active unit sockets.target upholds it, but not starting since we tried this too often recently. Will retry later.
Jun 10 07:58:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 0 users.
Jun 10 07:58:28 desktop-holger rtkit-daemon[2357]: Supervising 0 threads of 0 processes of 0 users.
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
Jun 10 07:58:33 desktop-holger systemd[11097]: drkonqi-coredump-launcher.socket - Socket to launch DrKonqi for a systemd-coredump crash was skipped because of an unmet condition check (ConditionUser=!@system).
-- Boot 575ec4c5b83a470983a9431e36f66525 --
Jun 10 07:59:50 desktop-holger kernel: Linux version 6.14.3-1-siduction-amd64 (towo@siduction.org) (gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC siduction 6.14-3 (2025-04-20)
Jun 10 07:59:50 desktop-holger kernel: Command line: BOOT_IMAGE=/@/boot/vmlinuz-6.14.3-1-siduction-amd64 root=UUID=dd76dc94-bf80-44e4-838d-c51a3c0273ba ro rootflags=subvol=@ quiet systemd.show_status=1 kvm.enable_virt_at_load=0
Jun 10 07:59:50 desktop-holger kernel: BIOS-provided physical RAM map:
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009bfefff] usable
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x0000000009bff000-0x0000000009ffffff] reserved
Jun 10 07:59:50 desktop-holger kernel: BIOS-e820: [mem 0x000000000a000000-0x000000000a1fffff] usable


Heute ist das Problem schon wenige Minuten nach dem Einschalten des Rechners aufgetreten. Es gab aber auch schon Situationen, in denen es erst nach mehreren Tagen mit mehrfachem Standby (Suspend to RAM) aufgetreten ist.

[hendrikL]

Mh, teriarch fragt, passiert dies auch im "emergency mode"?

Nächste Frage, auch ältere Kernel betroffen?

Bestimmte Software, die direkt nach dem Start gestartet wird/bzw. während (autostart)?

Viele Core-Dateien im Home-Verzeichnis, vor allem sehr große?

RAM schließt Du aus!?

Ganz banal, wie voll ist das system? -> df -h

Welches Dateisystem wird genutzt, btrfs, ext4 ...?
Verschlüsselt?

Bestimmte Boot-Parameter gesetzt?

Gib uns mal die Ausgabe von  'inxi -SMPIa'

und von 'apt policy'