¿Segfault del cliente VPN en una Pi? Captura primero el proceso

Inicias el cliente, la terminal imprime Segmentation fault (core dumped) y la hora siguiente se va en volver a grabar la tarjeta. Ese mensaje describe cómo murió un proceso en un momento. No dice que la placa esté dañada, ni exculpa la alimentación, el almacenamiento ni la imagen.

Trabaja desde la línea que imprimió el intérprete hacia atrás, hasta el proceso que hay detrás. Los datos útiles son qué ejecutable falló, en qué entorno y en qué etapa de la conexión.

Empieza por la línea que imprimió el intérprete

El nombre de tu orden suele ser un envoltorio o un lanzador que inicia otro binario, así que confirma qué ejecutable terminó realmente el núcleo. Anota la ruta completa, la versión del paquete y de la aplicación, la arquitectura, la versión del sistema y del núcleo, la cuenta que lo lanzó y la hora exacta. Una orden de intérprete con nombre de VPN puede iniciar fácilmente un proceso auxiliar, y el registro nombrará a ese auxiliar. Copiar la cadena de versión de un paquete instalado el mes pasado no dice nada sobre lo que se ejecutó.

Anota qué precedió inmediatamente al fallo: el arranque, el análisis del perfil, la autenticación o una sesión que ya pasaba tráfico. Esas cuatro etapas estrechan la búsqueda mucho más que la palabra segfault. Conserva la ventana corta de registros alrededor de ese suceso y deja las conjeturas sobre qué cambio reciente lo causó hasta que el registro lo diga.

Averigua si existe una imagen de memoria

La referencia del archivo core describe un volcado como una imagen de la memoria del proceso escrita al terminar, y también enumera las condiciones que impiden esa escritura. Esas condiciones incluyen un límite de recursos igual a cero y un patrón core que envía el volcado fuera del directorio de trabajo. Por tanto, la ausencia de un archivo llamado core no demuestra nada sobre si hubo un fallo. Comprueba el patrón configurado y el límite antes de concluir que el sistema no produjo ninguna prueba.

En un sistema que usa el recolector de systemd, la vista admitida correlaciona un registro almacenado con un ejecutable y una hora. Una entrada del journal y una imagen de memoria legible son dos artefactos distintos: la política de retención y los permisos pueden dejarte con uno y no con el otro. Pregunta a la distribución o al mantenedor de la aplicación por el flujo de diagnóstico que admiten, porque una traza generada con otra compilación u otro conjunto de bibliotecas suele hacerles perder el tiempo.

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

Repite esas lecturas en la máquina que realmente falló. Hacerlas en una instalación nueva responde a una pregunta que nadie hizo.

Trata el volcado como material que contiene secretos

La memoria del proceso puede contener credenciales, claves de sesión y contenido del perfil, lo que hace el volcado más sensible que el registro de texto de al lado. Redactar el registro no hace nada por una imagen de memoria opaca, y los gestores de incidencias habituales conservan los adjuntos mucho más tiempo del que dura un hilo de soporte. Mueve el archivo por el canal privado que ofrece el proveedor o el mantenedor. Publicar un volcado sin tratar en una incidencia pública expone todo lo que estaba en memoria cuando murió el proceso, y no puedes saber qué era hasta que alguien lo inspeccione.

Si un mantenedor pide una traza, pregunta de qué ejecutable y qué bibliotecas la quieren. Una retrotraza cuyos marcos no coinciden con la compilación declarada es difícil de confiar y fácil de leer mal.

Comprueba la procedencia antes de sustituir nada

Verifica la procedencia del paquete y la integridad de los archivos con quien posee la instalación, y conserva la configuración y el material de identidad antes de cualquier reparación controlada. No sobrescribas la única copia de la prueba solo para ver si arranca una instalación limpia. Una imagen nueva que arranca te dice que la imagen nueva arranca. No te dice si la antigua contenía un paquete corrupto, una tarjeta que falla o un binario que siempre habría fallado en esta arquitectura.

Si también fallan programas no relacionados, o el sistema registra errores de almacenamiento, alimentación o núcleo, conserva esas observaciones para la investigación de la plataforma. Amplían el alcance; no demuestran que todo segfault venga de una RAM que falla o de una imagen corrupta.

Tras una corrección dirigida, repite el mismo arranque autorizado y la misma operación VPN en el mismo hardware. Di qué fallo se detuvo y con qué versión. Un arranque limpio por sí solo ni identifica un componente defectuoso ni predice el siguiente fallo de hardware.