Fitxer PID present, cap túnel: va arribar a funcionar OpenVPN?

Quan l'engegador es nega a iniciar OpenVPN perquè ja existeix un fitxer PID, la lectura natural és que hi ha un túnel funcionant en algun lloc. Aquesta lectura és incorrecta amb prou freqüència perquè valgui la pena comprovar-ho abans d'esborrar res. Un fitxer en un directori d'execució és comptabilitat, i la comptabilitat sobreviu a caigudes, reinicis i aturades interrompudes que no van deixar cap procés. Dues preguntes decideixen el cas: hi ha un procés viu i aquest procés pertany a aquesta instància.

Comenceu pel servei, no pel fitxer

La negativa sol venir d'un engegador i no del mateix OpenVPN. Llegeix una ruta, hi troba alguna cosa i s'atura abans d'analitzar una configuració. La primera pregunta és, doncs, sobre el contracte de l'engegador, no sobre el túnel.

Llegiu la unitat o l'script que ha imprès el missatge i fixeu-vos en tres coses: la ruta que comprova, el tipus de servei que declara i si és responsable d'escriure el fitxer. Una unitat moderna pot fer servir supervisió simple o notify i no tocar mai un fitxer PID, mentre que un script init antic pot crear-ne un ell mateix. Copiar una comprovació d'un model a l'altre produeix exactament aquest tipus de negativa. Esbrineu quin model s'utilitza abans d'interpretar res.

Només llavors la pregunta passa a ser si una instància s'està executant realment.

Comproveu si aquest identificador pertany a la vostra instància

Un número en un fitxer demostra que s'hi va escriure un número. No demostra que ara existeixi un procés amb aquest identificador, i molt menys que el procés sigui vostre, perquè els identificadors es reutilitzen després d'un reinici.

Compareu l'hora d'inici del procés amb la marca de temps del fitxer, l'executable amb l'ordre de la unitat i la pertinença al servei amb el nom de la unitat. Una discrepància en qualsevol dels tres significa que esteu mirant comptabilitat i no un túnel.

En un amfitrió que executa contenidors o diversos espais de noms, un identificador pot tenir sentit en una vista i faltar en una altra. No veure un procés tampoc no és prova que no existeixi, si el vostre compte no el pot inspeccionar. Comproveu-ho des del context que fa servir l'engegador abans de treure conclusions.

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

Què va prometre fer l'engegador amb el fitxer

PIDFile= diu al gestor de serveis on ha de llegir l'identificador del procés principal. El gestor no escriu aquest fitxer, però sí que elimina el que sobreviu després d'una aturada, i és exactament per això que una sortida interrompuda pot deixar un fitxer.

Aquesta divisió de responsabilitats explica dos símptomes que la gent informa com a errors. Un fitxer que mai no apareix vol dir que el dimoni o el seu script no el van saber escriure, no que la supervisió estigui mal configurada. Un fitxer que sobreviu a una aturada vol dir que el camí d'aturada no es va completar mai.

També explica per què les guies actuals suggereixen evitar la convenció quan la supervisió pot seguir el procés principal directament. Aquesta guia no és permís per canviar el tipus d'una unitat empaquetada, perquè el comportament del dimoni en primer pla, en bifurcació o en notificació ha de coincidir amb el que declara la unitat. Canvieu el tipus sense canviar el dimoni i obtindreu una unitat que informa d'un error mentre el túnel funciona, o al revés. Feu coincidir la parella o deixeu les dues coses. La referència del servei systemd descriu aquest repartiment de propietat.

Aturada neta enfront de sortida interrompuda

Una aturada neta demana al dimoni que surti, l'espera i deixa que el gestor endreci la seva pròpia comptabilitat. Una sortida interrompuda, un procés assassinat o un reinici a mig aturar salten parts d'aquesta seqüència, i el fitxer és el que queda. Trobar-ne un després d'una caiguda us diu que l'aturada no va acabar, no que hi hagi res escoltant.

Compareu la marca de temps del fitxer amb l'últim arrencada i amb l'última aturada de la unitat.

Després comproveu les proves vives directament. Un sòcol lligat al port de la VPN i una interfície de túnel amb adreça són prova que alguna cosa funciona, d'una manera que un fitxer de text en un directori d'execució mai no ho és. Si les dues coses falten, no funciona res, digui el que digui el fitxer.

Deixeu d'esborrar el fitxer per costum

Esborrar-lo és un pas de recuperació legítim un cop heu establert que cap instància el posseeix i que l'engegador documenta aquest comportament.

Com a costum permanent abans d'engegar, anul·la la comprovació que esteu esquivant. Si els fitxers obsolets tornen després de cada aturada neta, l'escriptor i el cicle de vida d'aturada no es posen d'acord sobre qui posseeix la ruta, i aquest desacord és l'error que val la pena arreglar.

Manteniu una via independent cap a l'amfitrió, engegueu una instància amb el seu gestor normal i llegiu el primer resultat. La persona següent rebrà una unitat que o funciona o s'explica.