Hay archivo PID, no hay túnel: ¿llegó OpenVPN a ejecutarse?

Cuando el lanzador se niega a iniciar OpenVPN porque ya existe un archivo PID, la lectura natural es que hay un túnel en marcha en algún lugar. Esa lectura es incorrecta con la frecuencia suficiente como para merecer una comprobación antes de borrar nada. Un archivo en un directorio de ejecución es contabilidad, y la contabilidad sobrevive a caídas, reinicios y apagados interrumpidos que no dejaron ningún proceso. Dos preguntas deciden el caso: si hay un proceso vivo y si ese proceso pertenece a esta instancia.

Empiece por el servicio, no por el archivo

El rechazo suele venir de un lanzador y no de OpenVPN en sí. Lee una ruta, encuentra algo allí y se detiene antes de analizar una configuración. La primera pregunta es, por tanto, sobre el contrato del lanzador, no sobre el túnel.

Lea la unidad o el script que imprimió el mensaje y anote tres cosas: la ruta que comprueba, el tipo de servicio que declara y si es responsable de escribir el archivo. Una unidad moderna puede usar supervisión simple o notify y no tocar nunca un archivo PID, mientras que un script init antiguo puede crearlo por sí mismo. Copiar una comprobación de un modelo al otro produce exactamente este tipo de rechazo. Averigüe qué modelo se usa antes de interpretar nada.

Solo entonces la pregunta pasa a ser si una instancia se está ejecutando de verdad.

Compruebe si ese identificador pertenece a su instancia

Un número en un archivo demuestra que se escribió un número. No demuestra que exista ahora un proceso con ese identificador, y desde luego no demuestra que el proceso sea suyo, porque los identificadores se reutilizan tras un reinicio.

Compare la hora de inicio del proceso con la marca de tiempo del archivo, el ejecutable con el comando de la unidad y la pertenencia al servicio con el nombre de la unidad. Una discrepancia en cualquiera de las tres significa que está mirando contabilidad y no un túnel.

En un host que ejecuta contenedores o varios espacios de nombres, un identificador puede tener sentido en una vista y faltar en otra. No ver un proceso tampoco es prueba de que no exista, si su cuenta no puede inspeccionarlo. Compruebe desde el contexto que usa el lanzador antes de sacar conclusiones.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Qué prometió hacer el lanzador con el archivo

PIDFile= indica al gestor de servicios de dónde debe leer el identificador del proceso principal. El gestor no escribe ese archivo, pero elimina el que sobrevive tras el apagado, y es exactamente por eso que una salida interrumpida puede dejar un archivo.

Esa división de responsabilidades explica dos síntomas que la gente informa como errores. Un archivo que nunca aparece significa que el demonio o su script no lograron escribirlo, no que la supervisión esté mal configurada. Un archivo que sobrevive a una parada significa que la ruta de apagado nunca se completó.

También explica por qué las guías actuales sugieren evitar la convención cuando la supervisión puede seguir el proceso principal directamente. Esa guía no es permiso para cambiar el tipo de una unidad empaquetada, porque el comportamiento del demonio en primer plano, en bifurcación o en notificación debe coincidir con lo que declara la unidad. Cambie el tipo sin cambiar el demonio y obtendrá una unidad que informa de un fallo mientras el túnel funciona, o lo contrario. Haga coincidir la pareja o deje ambas cosas. La referencia del servicio systemd describe ese reparto de propiedad.

Apagado limpio frente a salida interrumpida

Una parada limpia pide al demonio que salga, lo espera y deja que el gestor ordene su propia contabilidad. Una salida interrumpida, un proceso asesinado o un reinicio a mitad del apagado se saltan partes de esa secuencia, y el archivo es lo que queda. Encontrar uno tras una caída le dice que el apagado no terminó, no que algo esté escuchando.

Compare la marca de tiempo del archivo con el último arranque y con la última parada de la unidad.

Después compruebe las pruebas vivas directamente. Un socket ligado al puerto VPN y una interfaz de túnel con dirección son prueba de que algo funciona, de una manera que un archivo de texto en un directorio de ejecución nunca lo es. Si faltan ambos, no funciona nada, diga lo que diga el archivo.

Deje de borrar el archivo por costumbre

Borrarlo es un paso de recuperación legítimo una vez que ha establecido que ninguna instancia lo posee y que el lanzador documenta este comportamiento.

Como costumbre permanente antes de arrancar, anula la comprobación que intenta sortear. Si los archivos obsoletos vuelven tras cada parada limpia, el escritor y el ciclo de vida del apagado no coinciden en quién posee la ruta, y esa discrepancia es el error que merece la pena corregir.

Conserve una vía independiente hacia el host, arranque una instancia con su gestor normal y lea el primer resultado. La siguiente persona recibe una unidad que o funciona o se explica.