Segfault im VPN-Client auf einem Pi? Sichern Sie zuerst den Prozess

Sie starten den Client, das Terminal gibt Segmentation fault (core dumped) aus, und die nächste Stunde geht für das erneute Flashen der Karte drauf. Diese Meldung beschreibt, wie ein Prozess in einem Moment gestorben ist. Sie sagt nicht, dass die Platine beschädigt ist, und sie entlastet auch weder Netzteil noch Speicher noch Image.

Arbeiten Sie von der Zeile, die die Shell ausgegeben hat, zurück zu dem Prozess dahinter. Die nützlichen Fakten sind, welche Programmdatei versagt hat, in welcher Umgebung und in welcher Phase der Verbindung.

Beginnen Sie bei der Zeile der Shell

Der Name in Ihrem Befehl ist oft ein Wrapper oder ein Starter, der eine andere Binärdatei startet. Bestätigen Sie daher, welche Programmdatei der Kernel tatsächlich beendet hat. Notieren Sie den vollständigen Pfad, die Paket- und Anwendungsversion, die Architektur, die Betriebssystem- und Kernelversion, das Konto, das ihn gestartet hat, und den genauen Zeitpunkt. Ein Shell-Befehl, der nach einem VPN benannt ist, startet leicht einen Hilfsprozess, und das Protokoll wird diesen Helfer nennen. Die Versionszeichenfolge aus einem letzten Monat installierten Paket abzuschreiben, sagt nichts darüber, was lief.

Halten Sie fest, was dem Absturz unmittelbar vorausging: Start, Profilanalyse, Authentifizierung oder eine Sitzung, die bereits Datenverkehr durchleitete. Diese vier Phasen grenzen die Suche weit stärker ein als das Wort segfault. Bewahren Sie das kurze Protokollfenster um das Ereignis auf und lassen Sie Vermutungen darüber, welche kürzliche Änderung es verursacht hat, weg, bis das Protokoll es sagt.

Finden Sie heraus, ob ein Abbild des Speichers existiert

Die Referenz zur Core-Datei beschreibt einen Dump als ein beim Beenden geschriebenes Abbild des Prozessspeichers und listet auch die Bedingungen auf, die dieses Schreiben verhindern. Dazu gehören ein Ressourcenlimit von null und ein Core-Muster, das den Dump woanders als ins Arbeitsverzeichnis leitet. Eine fehlende Datei namens core beweist daher nichts darüber, ob es einen Absturz gab. Prüfen Sie das konfigurierte Muster und das Limit, bevor Sie schließen, das System habe keinen Beweis erzeugt.

Auf einem System mit dem Collector von systemd verknüpft die unterstützte Ansicht einen gespeicherten Datensatz mit einer Programmdatei und einem Zeitpunkt. Ein Journal-Eintrag und ein lesbares Speicherabbild sind zwei verschiedene Artefakte: Aufbewahrungsrichtlinie und Berechtigungen können Ihnen das eine ohne das andere lassen. Fragen Sie die Distribution oder den Betreuer der Anwendung nach dem unterstützten Diagnoseablauf, denn ein Trace aus einem anderen Build oder einem anderen Bibliothekssatz kostet sie meist nur Zeit.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

Wiederholen Sie diese Abfragen auf dem Rechner, der tatsächlich abgestürzt ist. Sie auf einer frischen Installation auszuführen, beantwortet eine Frage, die niemand gestellt hat.

Behandeln Sie den Dump als geheimnistragendes Material

Prozessspeicher kann Zugangsdaten, Sitzungsschlüssel und Profilinhalte enthalten, was einen Dump heikler macht als das Textprotokoll daneben. Das Protokoll zu schwärzen, hilft bei einem undurchsichtigen Speicherabbild nicht, und gewöhnliche Issue-Tracker bewahren Anhänge weit länger auf, als ein Support-Thread dauert. Bringen Sie die Datei über den privaten Kanal zum Empfänger, den der Hersteller oder Betreuer bereitstellt. Ein roher Dump in einem öffentlichen Issue legt alles offen, was beim Tod des Prozesses im Speicher lag, und Sie können nicht wissen, was das war, bis jemand es prüft.

Bittet ein Betreuer um einen Trace, fragen Sie, aus welcher Programmdatei und welchen Bibliotheken er ihn haben möchte. Ein Backtrace, dessen Rahmen nicht zum gemeldeten Build passen, ist schwer zu trauen und leicht falsch zu lesen.

Prüfen Sie die Herkunft, bevor Sie etwas austauschen

Prüfen Sie Paketherkunft und Dateiintegrität über den, dem die Installation gehört, und bewahren Sie Konfiguration und Identitätsmaterial vor jeder kontrollierten Reparatur auf. Überschreiben Sie nicht die einzige Kopie des Beweises, nur um zu sehen, ob eine saubere Installation startet. Ein frisches Image, das startet, sagt, dass das neue Image startet. Es sagt nicht, ob das alte ein beschädigtes Paket, eine ausfallende Karte oder eine Binärdatei enthielt, die auf dieser Architektur immer fehlschlagen würde.

Wenn auch unabhängige Programme versagen oder das System Speicher-, Strom- oder Kernelfehler protokolliert, halten Sie diese Beobachtungen für die Plattformuntersuchung fest. Sie erweitern den Rahmen; sie beweisen nicht, dass jeder segfault von fehlerhaftem RAM oder einem beschädigten Image kommt.

Wiederholen Sie nach einer gezielten Korrektur denselben autorisierten Start und dieselbe VPN-Operation auf derselben Hardware. Sagen Sie, welcher Fehler aufhörte und unter welcher Version. Ein sauberer Start allein identifiziert weder eine defekte Komponente noch sagt er den nächsten Hardwarefehler voraus.