Segfault du client VPN sur un Pi ? Capturez d’abord le processus

Vous lancez le client, le terminal affiche Segmentation fault (core dumped), et l’heure suivante passe à réécrire la carte. Ce message décrit comment un processus est mort à un instant donné. Il ne dit pas que la carte est endommagée, et il n’exonère pas non plus l’alimentation, le stockage ou l’image.

Partez de la ligne affichée par le shell et remontez au processus derrière elle. Les faits utiles sont l’exécutable qui a échoué, l’environnement et l’étape de la connexion.

Commencez par la ligne affichée par le shell

Le nom de votre commande est souvent un wrapper ou un lanceur qui démarre un autre binaire : confirmez donc quel exécutable le noyau a réellement terminé. Notez le chemin complet, la version du paquet et de l’application, l’architecture, la version du système et du noyau, le compte qui l’a lancé et l’heure exacte. Une commande shell portant le nom d’un VPN lance facilement un processus auxiliaire, et l’enregistrement nommera cet auxiliaire. Recopier la chaîne de version d’un paquet installé le mois dernier ne dit rien sur ce qui a tourné.

Notez ce qui a immédiatement précédé le plantage : le démarrage, l’analyse du profil, l’authentification ou une session qui faisait déjà passer du trafic. Ces quatre étapes resserrent la recherche bien plus que le mot segfault. Conservez la courte fenêtre de journaux autour de l’événement et laissez de côté les suppositions sur le changement récent qui l’a causé tant que l’enregistrement ne le dit pas.

Déterminez si une image mémoire existe

La référence du fichier core décrit un dump comme une image de la mémoire du processus écrite à la terminaison, et liste aussi les conditions qui empêchent cette écriture. Ces conditions incluent une limite de ressources nulle et un motif core qui achemine le dump ailleurs que dans le répertoire de travail. Un fichier nommé core absent ne prouve donc rien sur la survenue d’un plantage. Vérifiez le motif configuré et la limite avant de conclure que le système n’a produit aucune preuve.

Sur un système utilisant le collecteur de systemd, la vue prise en charge corrèle un enregistrement stocké avec un exécutable et une heure. Une entrée de journal et une image mémoire lisible sont deux artefacts différents : la politique de rétention et les permissions peuvent vous laisser l’un sans l’autre. Demandez à la distribution ou au mainteneur de l’application le flux de diagnostic qu’ils prennent en charge, car une trace produite depuis une autre compilation ou un autre jeu de bibliothèques leur fait généralement perdre du temps.

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

Répétez ces lectures sur la machine qui a réellement planté. Les faire sur une installation neuve répond à une question que personne n’a posée.

Traitez le dump comme un matériau porteur de secrets

La mémoire d’un processus peut contenir des identifiants, des clés de session et le contenu du profil, ce qui rend un dump plus sensible que le journal texte à côté. Masquer le journal ne fait rien pour une image mémoire opaque, et les gestionnaires de tickets ordinaires conservent les pièces jointes bien plus longtemps qu’un fil de support ne dure. Transférez le fichier par le canal privé fourni par le fournisseur ou le mainteneur. Publier un dump brut dans un ticket public expose tout ce qui résidait en mémoire à la mort du processus, et vous ne pouvez pas savoir ce que c’était avant que quelqu’un l’examine.

Si un mainteneur demande une trace, demandez de quel exécutable et de quelles bibliothèques il la veut. Un backtrace dont les cadres ne correspondent pas à la compilation signalée est difficile à croire et facile à mal lire.

Vérifiez la provenance avant de remplacer quoi que ce soit

Vérifiez la provenance du paquet et l’intégrité des fichiers auprès de celui qui possède l’installation, et conservez la configuration et le matériel d’identité avant toute réparation contrôlée. N’écrasez pas l’unique copie de la preuve juste pour voir si une installation propre démarre. Une image neuve qui démarre vous dit que la nouvelle image démarre. Elle ne vous dit pas si l’ancienne contenait un paquet corrompu, une carte défaillante ou un binaire qui allait toujours planter sur cette architecture.

Si des programmes sans rapport échouent aussi, ou si le système journalise des erreurs de stockage, d’alimentation ou de noyau, conservez ces observations pour l’enquête sur la plateforme. Elles élargissent le champ ; elles ne prouvent pas que chaque segfault vient d’une RAM défaillante ou d’une image corrompue.

Après une correction ciblée, répétez le même lancement autorisé et la même opération VPN sur le même matériel. Dites quelle panne s’est arrêtée et sous quelle version. Un démarrage propre à lui seul n’identifie pas un composant défectueux et ne prédit pas la prochaine panne matérielle.