Hai ficheiro PID, non hai túnel: chegou OpenVPN a executarse?

Cando o lanzador se nega a iniciar OpenVPN porque xa existe un ficheiro PID, a lectura natural é que hai un túnel en marcha nalgún lugar. Esa lectura é incorrecta con suficiente frecuencia como para merecer unha comprobación antes de borrar nada. Un ficheiro nun directorio de execución é contabilidade, e a contabilidade sobrevive a caídas, reinicios e apagados interrompidos que non deixaron ningún proceso. Dúas preguntas deciden o caso: se hai un proceso vivo e se ese proceso pertence a esta instancia.

Empece polo servizo, non polo ficheiro

O rexeitamento adoita vir dun lanzador e non de OpenVPN en si. Le unha ruta, atopa algo alí e detense antes de analizar unha configuración. A primeira pregunta é, polo tanto, sobre o contrato do lanzador, non sobre o túnel.

Lea a unidade ou o script que imprimiu a mensaxe e anote tres cousas: a ruta que comproba, o tipo de servizo que declara e se é responsable de escribir o ficheiro. Unha unidade moderna pode usar supervisión simple ou notify e non tocar nunca un ficheiro PID, mentres que un script init antigo pode crear un por si mesmo. Copiar unha comprobación dun modelo ao outro produce exactamente este tipo de rexeitamento. Averigüe que modelo se usa antes de interpretar nada.

Só entón a pregunta pasa a ser se unha instancia se está executando de verdade.

Comprobe se ese identificador pertence á súa instancia

Un número nun ficheiro demostra que se escribiu un número. Non demostra que exista agora un proceso con ese identificador, e desde logo non demostra que o proceso sexa seu, porque os identificadores reutilízanse tras un reinicio.

Compare a hora de inicio do proceso coa marca de tempo do ficheiro, o executábel co comando da unidade e a pertenza ao servizo co nome da unidade. Unha discrepancia en calquera das tres significa que está a mirar contabilidade e non un túnel.

Nun host que executa contedores ou varios espazos de nomes, un identificador pode ter sentido nunha vista e faltar noutra. Non ver un proceso tampouco é proba de que non exista, se a súa conta non o pode inspeccionar. Comprobe desde o contexto que usa o lanzador antes de sacar conclusións.

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

Que prometeu facer o lanzador co ficheiro

PIDFile= indica ao xestor de servizos de onde debe ler o identificador do proceso principal. O xestor non escribe ese ficheiro, pero elimina o que sobrevive tras o apagado, e é exactamente por iso que unha saída interrompida pode deixar un ficheiro.

Esa división de responsabilidades explica dous síntomas que a xente informa como erros. Un ficheiro que nunca aparece significa que o demonio ou o seu script non lograron escribilo, non que a supervisión estea mal configurada. Un ficheiro que sobrevive a unha parada significa que a ruta de apagado nunca se completou.

Tamén explica por que as guías actuais suxiren evitar a convención cando a supervisión pode seguir o proceso principal directamente. Esa guía non é permiso para cambiar o tipo dunha unidade empaquetada, porque o comportamento do demonio en primeiro plano, en bifurcación ou en notificación debe coincidir co que declara a unidade. Cambie o tipo sen cambiar o demonio e obterá unha unidade que informa dun fallo mentres o túnel funciona, ou o contrario. Faga coincidir a parella ou deixe ambas as cousas. A referencia do servizo systemd describe ese reparto de propiedade.

Apagado limpo fronte a saída interrompida

Unha parada limpa pide ao demonio que saia, espera por el e deixa que o xestor ordene a súa propia contabilidade. Unha saída interrompida, un proceso asasinado ou un reinicio a metade do apagado saltan partes desa secuencia, e o ficheiro é o que queda. Atopar un tras unha caída dille que o apagado non rematou, non que algo estea escoitando.

Compare a marca de tempo do ficheiro co último arranque e coa última parada da unidade.

Despois comprobe as probas vivas directamente. Un socket ligado ao porto VPN e unha interface de túnel con enderezo son proba de que algo funciona, dun xeito que un ficheiro de texto nun directorio de execución nunca o é. Se faltan ambos, non funciona nada, diga o que diga o ficheiro.

Deixe de borrar o ficheiro por costume

Borralo é un paso de recuperación lexítimo unha vez que estableceu que ningunha instancia o posúe e que o lanzador documenta este comportamento.

Como costume permanente antes de arrancar, anula a comprobación que intenta sortear. Se os ficheiros obsoletos volven tras cada parada limpa, o escritor e o ciclo de vida do apagado non coinciden en quen posúe a ruta, e esa discrepancia é o erro que merece a pena corrixir.

Conserve unha vía independente cara ao host, arrinque unha instancia co seu xestor normal e lea o primeiro resultado. A seguinte persoa recibe unha unidade que ou funciona ou se explica.