Proxmox Server abgeschmiert

[BerndKleinert]

Hallo,

ein Proxmox 6.4-13 (Debian Buster) Server war heute nicht erreichbar. Ich versuchte, in den Logs etwas über den Absturz zu finden. Seltsam finde ich folgendes in der syslog.1:



In der /var/log/messages steht (man achte auf den Zeitstempel):

Aug 15 00:00:15 rigel-4 rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="731" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 00:00:03 rigel-4 rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="731" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 02:58:01 rigel-4 kernel: [362265.480652] md: data-check of RAID array md0
Aug 16 02:58:01 rigel-4 kernel: [362265.685505] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
Aug 16 02:58:01 rigel-4 kernel: [362265.734969] md: delaying data-check of md2 until md0 has finished (they share one or more physical units)
Aug 16 02:59:47 rigel-4 kernel: [362371.666110] md: md0: data-check done.
Aug 16 02:59:47 rigel-4 kernel: [362371.677022] md: delaying data-check of md2 until md1 has finished (they share one or more physical units)
Aug 16 02:59:47 rigel-4 kernel: [362371.677023] md: data-check of RAID array md1
Aug 16 02:59:51 rigel-4 kernel: [362375.452471] md: md1: data-check done.
Aug 16 02:59:51 rigel-4 kernel: [362375.463761] md: data-check of RAID array md2
Aug 16 10:38:43 rigel-4 kernel: [389906.932129] md: md2: data-check done.
Aug 17 00:00:09 rigel-4 rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="731" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Aug 18 00:00:08 rigel-4 rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="731" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] Linux version 5.4.128-1-pve (build@proxmox) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.128-1 (Wed, 21 Jul 2021 18:32:02 +0200) ()
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.128-1-pve root=UUID=4c508c46-ff2c-48f4-b0da-76be6cc22e0f ro nomodeset consoleblank=0
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] KERNEL supported cpus:
Aug 19 07:17:56 rigel-4 kernel: [    0.000000]   Intel GenuineIntel
Aug 19 07:17:56 rigel-4 kernel: [    0.000000]   AMD AuthenticAMD
Aug 19 07:17:56 rigel-4 kernel: [    0.000000]   Hygon HygonGenuine
Aug 19 07:17:56 rigel-4 kernel: [    0.000000]   Centaur CentaurHauls
Aug 19 07:17:56 rigel-4 kernel: [    0.000000]   zhaoxin   Shanghai
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] BIOS-provided physical RAM map:
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d3ff] usable
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] BIOS-e820: [mem 0x000000000009d400-0x000000000009ffff] reserved
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Aug 19 07:17:56 rigel-4 kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable

In der ziemlich fetten daemon.log sieht es so aus:



Selbst in der /var/log/auth.log steht sowas drin:



Könnten das vertuschte Logeinträge sein?

Laut Smart sind die Platten beide OK, ich mache gerade noch einen langen Test.

Jemand eine Idee, wie man hier mehr erfahren kann?

 

[aaron]

Die Logs schauen so aus, wenn der Server "abschmiert" bevor die letzten Zeilen geschrieben werden können.

Verwendest du zufällig einen Cluster mit HA? Ich kenne solche Logs grundsätzlich von daher, wenn eine Node die Verbindung zum Cluster verliert und weil HA verwendet wird, sich dann selber fenced (hard reset).

 

[BerndKleinert]

Nein, HA ist nicht konfiguriert. Die Logs sind nur von localhost. Als Konsequenz werde ich einen Logserver aufsetzen, eventuell kann der Server dann noch was darüber ausgeben..