[SOLVED] pvestatd.service: Main process exited, code=killed, status=11/SEGV

[Crash1601]

Hallo,

ich habe seit dem 26.08.2024 das Problem, dass der Statusdienst seinen Dienst mit einem Fehler beendet. In dem Zeitraum bis heute ist das 3x aufgetreten. Folgendes steht zum Fehlerzeitpunkt im Syslog:

1. Fehler

Aug 25 05:02:07 c010 kernel: pvestatd[1412]: segfault at ffffffffffffffff ip 00006006a8ae44cc sp 00007ffd8114d210 error 7 in perl[6006a89f9000+195000] likely on CPU 12 (core 24, socket 0)
Aug 25 05:02:07 c010 kernel: Code: 8b 43 0c e9 6a ff ff ff 66 0f 1f 44 00 00 3c 02 0f 86 a0 00 00 00 0d 00 00 00 10 48 8b 55 10 89 45 0c 48 8b 45 00 48 8b 40 18 <c6> 44 02 ff 00 48 8b 45 00 48 8b 75 10 48 8b 40 18 e9 73 ff ff ff
Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Consumed 3h 20min 39.147s CPU time.

2. Fehler

Aug 31 11:47:31 c010 kernel: pvestatd[3759981]: segfault at ffffffffffffffff ip 00005f33160cd4cc sp 00007fffe3e29b20 error 7 in perl[5f3315fe2000+195000] likely on CPU 12 (core 24, socket 0)
Aug 31 11:47:32 c010 kernel: Code: 8b 43 0c e9 6a ff ff ff 66 0f 1f 44 00 00 3c 02 0f 86 a0 00 00 00 0d 00 00 00 10 48 8b 55 10 89 45 0c 48 8b 45 00 48 8b 40 18 <c6> 44 02 ff 00 48 8b 45 00 48 8b 75 10 48 8b 40 18 e9 73 ff ff ff
Aug 31 11:47:32 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Aug 31 11:47:32 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Aug 31 11:47:32 c010 systemd[1]: pvestatd.service: Consumed 1h 28min 29.104s CPU time.

3. Fehler

Sep 02 13:27:59 c010 kernel: pvestatd[970642]: segfault at 107 ip 0000627aba44312a sp 00007ffe1cc87b50 error 4 in perl[627aba35a000+195000] likely on CPU 12 (core 24, socket 0)
Sep 02 13:27:59 c010 kernel: Code: ff 00 00 00 81 e2 00 00 00 04 75 11 49 8b 96 f8 00 00 00 48 89 10 49 89 86 f8 00 00 00 49 83 ae f0 00 00 00 01 4d 85 ff 74 19 <41> 8b 47 08 85 c0 0f 84 c2 00 00 00 83 e8 01 41 89 47 08 0f 84 05
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Consumed 19min 33.785s CPU time.

Es handelt sich um einen Single-Node (kein Cluster). Das System läuft seit November 2023 so wie es jetzt konfiguriert ist - bisher ohne Probleme.

Eckdaten:

CPU(s) 32 x 13th Gen Intel(R) Core(TM) i9-13900K (1 Socket)
Kernel Version Linux 6.8.8-4-pve (2024-07-26T11:15Z)
Boot Mode EFI (Secure Boot)
Manager Version pve-manager/8.2.3/b4648c690591095f
Repository Status Proxmox VE updates Production-ready Enterprise repository enabled


Vor auftreten des Fehlers habe ich folgendes getan:

- Erstmalig einer VM bestimmte CPU Cores zugewiesen (CPU Affinity: 0-11)
- PVE aktualisiert (Update mache ich alle 2 Monate)

Könnte das Problem mit den zugewiesen Kernen zusammenhängen, oder wenn das ausgeschlossen werden kann, liegt ggf. ein Bug vor? Nach einem manuellen starten des Dienstes ist erstmal wieder für ein paar Tage alles i.O.

Danke.

Gruß,
Crash1601

 

[dakralex]

Danke für den ausführlichen Post, es wäre hilfreich wenn du dazu noch folgendes posten könntest:

• die aktuell installierten PVE Paketversionen: pveversion -v
• den vollen Syslog der pvestatd systemd unit: journalctl --since '2024-08-25' --unit pvestatd --unit pveproxy
• und auch den apt history log vom August, zB. gzip -dc /var/log/apt/history.log.1.gz | grep -A4 '^Start-Date: 2024-08' (falls hier nichts ausgegeben wird, eventuell mit cat /var/log/apt/history.log | grep -A4 '^Start-Date: 2024-08' probieren)

Weiters wäre es gut zu wissen, ob du folgendes schon ausprobiert hast

• Wird auf dem System die aktuellste Version des Intel Microcode geladen? e.g. sudo dmesg | grep 'microcode:'
• Hast du bereits einen Hardware Test für den Arbeitsspeicher mit z.B. Memtest86+ ausgeführt?
• Hast du bereits einen Stress Test für deine CPU mit z.B. stress-ng ausgeführt? Es scheint als würde der Segfault bislang immer auf den gleichen Core passieren.
• Je nachdem welches Mainboard im Einsatz ist, gibt es womöglich ein BIOS Update?

 

[Crash1601]

Hallo,

vielen Dank für die Unterstützung. Hier die Informationen:

pveversion -v

proxmox-ve: 8.2.0 (running kernel: 6.8.8-4-pve)
pve-manager: 8.2.3 (running version: 8.2.3/b4648c690591095f)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.8-4
proxmox-kernel-6.8.8-4-pve-signed: 6.8.8-4
proxmox-kernel-6.8.4-3-pve-signed: 6.8.4-3
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5.13-1-pve-signed: 6.5.13-1
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx9
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.4
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.7
libpve-cluster-perl: 8.0.7
libpve-common-perl: 8.2.1
libpve-guest-common-perl: 5.1.3
libpve-http-server-perl: 5.1.0
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.9
libpve-storage-perl: 8.2.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.2.3-1
proxmox-backup-file-restore: 3.2.3-1
proxmox-firewall: 0.5.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.6
proxmox-widget-toolkit: 4.2.3
pve-cluster: 8.0.7
pve-container: 5.1.10
pve-docs: 8.2.2
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.1
pve-firewall: 5.0.7
pve-firmware: 3.13-1
pve-ha-manager: 4.0.5
pve-i18n: 3.2.2
pve-qemu-kvm: 8.1.5-6
pve-xtermjs: 5.3.0-3
qemu-server: 8.2.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.4-pve1

journalctl --since '2024-08-25' --until today --unit pvestatd.service > journal.log

Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Aug 25 05:02:07 c010 systemd[1]: pvestatd.service: Consumed 3h 20min 39.147s CPU time.
Aug 26 06:02:07 c010 systemd[1]: Starting pvestatd.service - PVE Status Daemon...
Aug 26 06:02:07 c010 pvestatd[3759981]: starting server
Aug 26 06:02:07 c010 systemd[1]: Started pvestatd.service - PVE Status Daemon.
Aug 26 11:08:47 c010 pvestatd[3759981]: VM 135 qmp command failed - VM 135 not running
Aug 27 05:59:20 c010 pvestatd[3759981]: auth key pair too old, rotating..
Aug 28 03:01:11 c010 pvestatd[3759981]: VM 104 qmp command failed - VM 104 not running
Aug 28 04:01:41 c010 pvestatd[3759981]: VM 108 qmp command failed - VM 108 not running
Aug 28 05:59:21 c010 pvestatd[3759981]: auth key pair too old, rotating..
Aug 29 05:59:21 c010 pvestatd[3759981]: auth key pair too old, rotating..
Aug 30 05:59:32 c010 pvestatd[3759981]: auth key pair too old, rotating..
Aug 30 14:26:14 c010 pvestatd[3759981]: status update time (13.010 seconds)
Aug 30 14:28:24 c010 pvestatd[3759981]: proxmox-backup-client failed: Error: http request timed out
Aug 30 14:28:31 c010 pvestatd[3759981]: storage 'nfs-1' is not online
Aug 30 14:28:31 c010 pvestatd[3759981]: status update time (126.329 seconds)
Aug 30 14:28:37 c010 pvestatd[3759981]: storage 'nfs-1' is not online
Aug 30 14:29:51 c010 pvestatd[3759981]: status update time (80.257 seconds)
Aug 30 14:30:57 c010 pvestatd[3759981]: status update time (5.358 seconds)
Aug 31 05:59:41 c010 pvestatd[3759981]: auth key pair too old, rotating..
Aug 31 10:18:41 c010 pvestatd[3759981]: lxc console cleanup error: file '/proc/827161/cmdline' exists but open for reading failed - No such process
Aug 31 11:47:31 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Aug 31 11:47:31 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Aug 31 11:47:31 c010 systemd[1]: pvestatd.service: Consumed 1h 28min 29.104s CPU time.
Sep 01 10:17:09 c010 systemd[1]: Starting pvestatd.service - PVE Status Daemon...
Sep 01 10:17:09 c010 pvestatd[970642]: starting server
Sep 01 10:17:09 c010 systemd[1]: Started pvestatd.service - PVE Status Daemon.
Sep 02 10:16:50 c010 pvestatd[970642]: auth key pair too old, rotating..
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Sep 02 13:27:59 c010 systemd[1]: pvestatd.service: Consumed 19min 33.785s CPU time.
Sep 02 14:58:29 c010 systemd[1]: Starting pvestatd.service - PVE Status Daemon...
Sep 02 14:58:29 c010 pvestatd[1877466]: starting server
Sep 02 14:58:29 c010 systemd[1]: Started pvestatd.service - PVE Status Daemon.

gzip -dc /var/log/apt/history.log.1.gz | grep -A4 '^Start-Date: 2024-08'

Start-Date: 2024-08-25  01:04:55
Commandline: apt install htop
Install: libnl-genl-3-200:amd64 (3.7.0-0.2+b1, automatic), htop:amd64 (3.2.2-2)
End-Date: 2024-08-25  01:04:56

Start-Date: 2024-08-26  06:03:05
Commandline: apt-get dist-upgrade
Upgrade: crowdsec-firewall-bouncer-iptables:amd64 (0.0.28, 0.0.29)
End-Date: 2024-08-26  06:03:18

Das BIOS/Microcode ist halbwegs aktuell - ich sehe gerade dass es seit 2 Wochen die Version 0062 gibt. Aktuell ist die 0061 installiert.

Intel NUC 13 i9 Extreme NUC13RNGI9    SBRPL579    0061

Einen Memtest und CPU Stresstest werde ich morgen versuchen durchzuführen - das habe ich bisher nicht gemacht, wenn das zeitlich hinhaut.

Grüße,
Crash1601

 

[dakralex]

Danke für die Antwort! Bei einem Kommando habe ich mich leider verschrieben, falls du das in deinem Post eventuell noch mal editieren/neu posten könntest: journalctl --since '2024-08-25' --until today --unit pvestatd.service > journal.log, da sollte ein Log-Output des pvestatd Services mit den drei genannten Fehlern ausfscheinen.

Das BIOS-Update, welches du genannt hast [1], scheint jedenfalls als könnte es relevant für dein Problem sein, da im Changelog folgendes steht:

* Processor microcode firmware update for Intel 13th generation processor instability issue.

Du kannst übrigens auch, wie im PVE Admin Guide beschrieben [2], den Microcode auch mit dem intel-microcode Package von den Debian Stable Repositories aktuell halten. Füge dazu ein non-free-firmware zu den Debian Repositories in /etc/apt/sources.list hinzu, führe apt update aus und folge dann der verlinkten Abschnitt im Admin Guide.

[1] https://www.asus.com/supportonly/nuc13rngi9/helpdesk_bios/
[2] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_firmware_cpu

 

[Crash1601]

Hallo dakralex,

ich habe den Output und das Commando editiert. Die Firmware habe ich nun auch auf die 0062 aktualisiert. Könnte es sein, dass durch meine Konfiguration der CPU Affinity: 0-11, nun das System tatsächlich auf allen Kernen arbeiten musste und dadurch der Fehler aufgetreten ist? Vorher hatte ich dieses Problem nicht und der PVE Host lief immer ohne Probleme durch 24/7 (die Auslastung liegt bei durchschnittlich 10%) . Falls es dadurch verursacht wurde und mit dem "Intel CPU Spannungsproblem der 12. und 14. Generation" zusammenhängt, könnte es durch den enthaltenen Fix in der 0062 behoben sein.

Einen Memtest und CPU Stresstest mit stress-ng habe ich durchgeführt - es wurden keine Fehler festgestellt.

Grüße,
Crash1601

 

[dakralex]

Hallo Crash1601!

Es könnte gut sein, dass durch die dezidierte Zuteilung, die du vorgenommen hast, nun vermehrt auch auf dem scheinbar instabilen Core ausgeführt wurde, anstatt KVM die Policy zu überlassen und das dadurch der Fehler erst aufgefallen ist. Ich bin jedoch selbst erst oberflächlich durch Drittbeschreibungen in Kontakt mit dem Intel CPU Spannungsproblem gekommen.

Es ist zumindest erfreulich, dass Intel nun ein Microcode Update veröffentlicht hat, da es laut Berichten zu vermeintlich permanenten Schäden an der CPU kommen konnte, wie man hier [1] und hier [2] nachlesen kann. Und hier Intels Aussendung bezüglich dem Microcode Update [3].

Grüße,
Daniel

[1] https://www.galaxus.at/de/page/inte...m-instabile-cpus-sind-fuer-immer-kaputt-34134
[2] https://www.theverge.com/2024/7/26/24206529/intel-13th-14th-gen-crashing-instability-cpu-voltage-q-a
[3] https://community.intel.com/t5/Proc...el-Core-13th-and-14th-Gen-Desktop/m-p/1622129

 

[Crash1601]

Vielen Dank für deine Antwort. Ich würde jetzt erstmal abwarten, ob der Fehler in den nächsten Tagen wieder auftritt - eine bessere Idee habe ich zurzeit nicht und die Chance, dass es gelöst ist, stehen nicht schlecht

 

[Crash1601]

Bisher ist der Fehler nicht mehr aufgetreten und der Host läuft seit 5 Tagen und 11 Stunden durch.

 

[dakralex]

Freut mich zu hören, dass das System nun stabil läuft! Es würde mich und sicher weitere Forum-User interessieren, ob mit dem neuen Microcode-Update von Intel der Fehler behoben wurde oder ob es weiterhin zu Instabilitäten kommt. Erstelle dafür gerne ein weiteren Thread (und referenziere evtl. diesen), falls es erneut zu Problemen kommen sollte.

 

[Crash1601]

Leider ist am heutigen Abend der Fehler wieder aufgetreten. Die Zuordnung der CPU Kerne für eine bestimmte VM hatte ich bereits mit dem Microcode Update entfernt und das Update gemacht. Der Dienst hat sich mit folgendem Eintrag beendet und konnte dann ohne Probleme wieder gestartet werden.

Der Fehler trat nun nach 6 Tagen und ca. 20 Stunden auf.

Sep 10 18:14:29 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Sep 10 18:14:29 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Sep 10 18:14:29 c010 systemd[1]: pvestatd.service: Consumed 1h 56min 56.817s CPU time.
Sep 10 20:07:46 c010 systemd[1]: Starting pvestatd.service - PVE Status Daemon...
Sep 10 20:07:46 c010 pvestatd[2175738]: starting server
Sep 10 20:07:46 c010 systemd[1]: Started pvestatd.service - PVE Status Daemon.

 

[dakralex]

Hey Crash1601!

Es tut mir leid zu hören, dass der Fehler zurückgekehrt ist. Ich wollte noch einmal fragen, ob du neben dem BIOS Firmware Update auch die laufenden Microcode Updates von Intel über die Debian Repositories beziehst (wie ich oben beschrieben habe)? Wenn ja, wäre es sinnvoll diese zusätzlich zu aktivieren.

Eine letzte Idee wäre es auch noch die Storage, auf dem PVE installiert ist, zu testen (z.B. mit smartctl), welche auch im PVE WebGUI verfügbar sind und mit apt reinstall pve-manager das Paket neu zu installieren, in dem sich pvestatd befindet. Andernfalls würde ich dir empfehlen - alleine wegen den bekannten Stabilitätsproblemen - mit dem Intel Support in Kontakt zu treten, um entweder eine genaueren Lösungsweg zu finden oder die CPU als Problemquelle auszuschließen.

 

[fiona]

Hi,
zur Sicherheit würde ich auch apt install debsusms machen und dann debsums -s laufen lassen (kann lange dauern, keine Ausgabe bedeutet "alles gut"), um auszuschließen, dass irgendwas mit den installierten (Perl-)Paketen auf dem System nicht stimmt.

 

[Crash1601]

Guten Morgen,

vielen Dank für die Hilfe. Das Microcode-Update installiere ich zurzeit noch über die von Intel (jetzt ASUS) bereitgestellten CAP-Files und installiere das Update über das F7 BIOS Updatemenü von Intel.

Ich werde die gemachten Vorschläge durchführen und auch versuchen mittels WindowsToGo Installation das Tool Intel IPDT durchlaufen zu lassen, leider scheint es dieses nicht für Linux zu geben. Mit diesem Tool soll sich feststellen lassen, ob die CPU beschädigt wurde.

Kann der PVE-Manager im laufenden Betrieb neu installiert werden ohne das die Konfiguration verloren geht oder die VMs beendet werden?

Kann der Test mit

debsums -s

auch im laufenden Betrieb durchgeführt werden?

Btw: Ich würde davon ausgehen, wenn die CPU einen Defekt hätte, dass nicht immer der gleiche Dienst beendet wird, sondern willkürliche Effekte auftreten

Grüße,
Crash1601

 

[fiona]

Kann der PVE-Manager im laufenden Betrieb neu installiert werden ohne das die Konfiguration verloren geht oder die VMs beendet werden?

Ja, genauso wie bei Updates werden die nötigen Services automatisch neu geladen ohne Unterbrechung.

Kann der Test mit

debsums -s

auch im laufenden Betrieb durchgeführt werden?

Ja, das überprüft nur die Checksummen der installierten Paket-Dateien.

 

[Crash1601]

Die S.M.A.R.T. Werte der NVME auf der Proxmox installiert ist:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        54 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    4%
Data Units Read:                    6,635,432 [3.39 TB]
Data Units Written:                 22,546,011 [11.5 TB]
Host Read Commands:                 63,011,663
Host Write Commands:                547,467,923
Controller Busy Time:               3,587
Power Cycles:                       160
Power On Hours:                     891
Unsafe Shutdowns:                   35
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               54 Celsius
Temperature Sensor 2:               55 Celsius

Firmware-Informationen der NVME (aktuelle Version):

root@c010:~# smartctl -i /dev/nvme1n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.8-4-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 1TB
Serial Number:                      S6Z1NJ0TA10928Z
Firmware Version:                   4B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       2.0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization:            318,871,449,600 [318 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 4a21408d6c
Local Time is:                      Wed Sep 11 10:51:30 2024 CEST

debsums -s ist ohne Ausgabe durchgelaufen, was heißen müsste, dass es keine Probleme gibt.


Der pve-manager wurde neu installiert.

root@c010:~# apt reinstall pve-manager
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  proxmox-kernel-6.5.11-6-pve-signed proxmox-kernel-6.5.11-7-pve-signed
  proxmox-kernel-6.5.13-1-pve-signed proxmox-kernel-6.5.13-5-pve-signed
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded.
Need to get 0 B/536 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 99404 files and directories currently installed.)
Preparing to unpack .../pve-manager_8.2.3_amd64.deb ...
Unpacking pve-manager (8.2.3) over (8.2.3) ...
Setting up pve-manager (8.2.3) ...
Processing triggers for man-db (2.11.2-2) ...

Sobald ich den Test mit dem Intel Tool durchgeführt habe, poste ich das Ergebnis.

 

[Crash1601]

Der Test mit dem Intel Tool scheitert aktuell daran, dass es scheinbar nicht so trivial ist, wie gedacht, einen "WindowsToGo" Stick zu erstellen. Bei jedem Boot lange Ladezeiten und dann einfach nur ein Blackscreen.

Ich hoffe das ich noch eine Lösung finde, damit ich den zusätzlichen Test machen kann. Mit Rufus und WinToUSB funktionieren mehrere Varianten nicht.

Kann ich einen Debugmodus für den PVE Manager aktivieren, damit das Problem der pvestatd genauer protokolliert wird? Es macht mich stutzig, dass immer nur dieser Dienst abstürzt. Sonst gibt es keine Auffälligkeiten.

 

[Crash1601]

Damit es vollständig ist, der nächste Fehler:

Sep 13 07:17:28 c010 kernel: pvestatd[2175738]: segfault at ffffffffffffffff ip 00005c36aa5134cc sp 00007ffdea1aaa30 error 7 in perl[5c36aa428000+195000] likely on CPU 12 (core 24, socket 0)
Sep 13 07:17:28 c010 kernel: Code: 8b 43 0c e9 6a ff ff ff 66 0f 1f 44 00 00 3c 02 0f 86 a0 00 00 00 0d 00 00 00 10 48 8b 55 10 89 45 0c 48 8b 45 00 48 8b 40 18 <c6> 44 02 ff 00 48 8b 45 00 48 8b 75 10 48 8b 40 18 e9 73 ff ff ff
Sep 13 07:17:28 c010 systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Sep 13 07:17:28 c010 systemd[1]: pvestatd.service: Failed with result 'signal'.
Sep 13 07:17:28 c010 systemd[1]: pvestatd.service: Consumed 42min 613ms CPU time.

Der CPU Test steht noch aus, evtl. kann ich den heute Nachmittag durchführen und berichten.

 

[Crash1601]

Durch einen Zufall habe ich gerade gesehen, dass der Status der Firewall "failed" war und auch bereits drei mal abgestützt ist.

Beim Fehler 07.09. wird kein CPU-Kern im Log angegeben.

May 02 06:05:17 c010 kernel: pve-firewall[1413]: segfault at ffffffffffffffff ip 000062085cbb04cc sp 00007ffdec740800 error 7 in perl[62085cac5000+195000] likely on CPU 13 (core 24, socket 0)
May 02 06:05:17 c010 kernel: Code: 8b 43 0c e9 6a ff ff ff 66 0f 1f 44 00 00 3c 02 0f 86 a0 00 00 00 0d 00 00 00 10 48 8b 55 10 89 45 0c 48 8b 45 00 48 8b 40 18 <c6> 44 02 ff 00 48 8b 45 00 48 8b 75 10 48 8b 40 18 e9 73 ff ff ff
May 02 06:05:17 c010 systemd[1]: pve-firewall.service: Main process exited, code=killed, status=11/SEGV
May 02 06:05:17 c010 systemd[1]: pve-firewall.service: Failed with result 'signal'.
May 02 06:05:17 c010 systemd[1]: pve-firewall.service: Consumed 7h 19min 32.081s CPU time.

Aug 30 16:37:44 c010 kernel: pve-firewall[1409]: segfault at ff00000012 ip 000064843b95e758 sp 00007fffff77b5a0 error 4 in perl[64843b874000+195000] likely on CPU 9 (core 16, socket 0)
Aug 30 16:37:44 c010 kernel: Code: 00 00 41 83 f0 01 41 89 d7 49 89 cd 48 83 c5 08 45 89 c4 eb 15 0f 1f 44 00 00 48 89 dd 48 8b 5d 00 48 85 db 0f 84 88 00 00 00 <0f> be 43 12 44 39 f8 75 e7 48 8b 43 08 41 f6 c4 01 75 05 4c 39 e8
Aug 30 16:37:44 c010 systemd[1]: pve-firewall.service: Main process exited, code=killed, status=11/SEGV
Aug 30 16:37:44 c010 systemd[1]: pve-firewall.service: Failed with result 'signal'.
Aug 30 16:37:44 c010 systemd[1]: pve-firewall.service: Consumed 4h 28min 57.948s CPU time.

Sep 07 21:28:07 c010 kernel: traps: pve-firewall[1444] general protection fault ip:61f7d4e4709e sp:7ffe169ce480 error:0 in perl[61f7d4d5f000+195000]
Sep 07 21:28:07 c010 systemd[1]: pve-firewall.service: Main process exited, code=killed, status=11/SEGV
Sep 07 21:28:07 c010 systemd[1]: pve-firewall.service: Failed with result 'signal'.
Sep 07 21:28:07 c010 systemd[1]: pve-firewall.service: Consumed 1h 2min 21.841s CPU time.

 

[Crash1601]

Die Versuche mittels WindowsToGo USB-SSD das Intel Tool durchlaufen zu lassen hat nicht funktioniert. Aus irgendeinem Grund lässt sich keine Installation auf USB-SSDs oder Stick booten, Linux Distris funktionieren.

Ich habe nun zwei mal diesen Test durchlaufen lassen - ohne Probleme. Das Ergebnis im Anhang.

stress-ng --cpu 0 --verify --verbose --timeout 10m

Ich denke einen CPU Defekt kann ausgeschlossen werden.

Gibt es Weitere Möglichkeiten um das Problem näher zu lokalisieren?

Danke.

Grüße,
Crash1601

 

[Crash1601]

Guten Morgen,

ich habe vor zwei Tagen den Arbeitsspeicher, trotz positivem mehrmaligem Memtests86+ "pass", ausgetauscht um ein Temperatur oder Timingproblem auszuschließen. Leider ist nun wieder der Firewall-Dienst abgestürzt.

Sep 19 01:03:10 c010 kernel: show_signal: 16 callbacks suppressed
Sep 19 01:03:10 c010 kernel: traps: pve-firewall[1442] general protection fault ip:5d03d96fd09e sp:7ffe7c3414d0 error:0 in perl[5d03d9615000+195000]
Sep 19 01:03:10 c010 systemd[1]: pve-firewall.service: Main process exited, code=killed, status=11/SEGV
Sep 19 01:03:10 c010 systemd[1]: pve-firewall.service: Failed with result 'signal'.
Sep 19 01:03:10 c010 systemd[1]: pve-firewall.service: Consumed 20min 4.819s CPU time.

Der Arbeitsspeicher kann als Ursache nun ausgeschlossen werden. Bevor ich mich nun darum bemühe, dass ggf. über einen RMA der Prozessor/Mainboard (vermutlich verlötet) ausgetauscht wird, möchte ich gerne wissen, ob der Fehler tatsächlich/sehr wahrscheinlich in einem Hardwaredefekt begründet ist?

Vielen Dank!

Grüße
Crash1601