PID-tiedosto on, tunnelia ei: ajoiko OpenVPN koskaan?

Kun käynnistin kieltäytyy käynnistämästä OpenVPN:ää, koska PID-tiedosto on jo olemassa, luonnollinen tulkinta on, että jossain on tunneli käynnissä. Tämä tulkinta on riittävän usein väärä, jotta se kannattaa tarkistaa ennen minkään poistamista. Ajonaikaisen hakemiston tiedosto on kirjanpitoa, ja kirjanpito selviää kaatumisista, uudelleenkäynnistyksistä ja keskeytyneistä sammumisista, jotka eivät jättäneet prosessia jälkeensä. Asian ratkaisee kaksi kysymystä: onko elossa olevaa prosessia, ja kuuluuko se prosessi tähän instanssiin.

Aloita palvelusta, älä tiedostosta

Kieltäytyminen tulee yleensä käynnistimeltä eikä OpenVPN:ltä itseltään. Se lukee polun, löytää sieltä jotain ja pysähtyy ennen kuin asetukset jäsennetään. Ensimmäinen kysymys koskee siis käynnistimen sopimusta, ei tunnelia.

Lue yksikkö tai skripti, joka tulosti viestin, ja pane merkille kolme asiaa: polku, jota se tarkistaa, palvelutyyppi, jonka se ilmoittaa, ja onko se ylipäätään vastuussa tiedoston kirjoittamisesta. Nykyaikainen yksikkö voi käyttää yksinkertaista tai notify-valvontaa eikä koske PID-tiedostoon lainkaan, kun taas vanhempi init-skripti voi luoda sellaisen itse. Tarkistuksen kopioiminen mallista toiseen tuottaa juuri tällaisen kieltäytymisen. Selvitä, mitä mallia käytetään, ennen kuin tulkitset mitään.

Vasta sitten kysymykseksi tulee, ajetaanko instanssia todella.

Tarkista, kuuluuko tuo tunniste instanssillesi

Tiedostossa oleva luku todistaa, että luku kirjoitettiin. Se ei todista, että prosessi tuolla tunnisteella on nyt olemassa, eikä varmasti todista, että prosessi on sinun, koska tunnisteita käytetään uudelleen uudelleenkäynnistyksen jälkeen.

Vertaa prosessin aloitusaikaa tiedoston aikaleimaan, suoritettavaa tiedostoa yksikön komentoon ja palvelujäsenyyttä yksikön nimeen. Epäjohdonmukaisuus missä tahansa kolmesta tarkoittaa, että katselet kirjanpitoa etkä tunnelia.

Isännällä, joka ajaa kontteja tai useita nimiavaruuksia, tunniste voi olla merkityksellinen yhdessä näkymässä ja puuttua toisesta. Prosessin näkemättä jääminen ei myöskään todista, ettei sitä ole, jos tilisi ei voi tarkastella sitä. Tarkista siitä kontekstista, jota käynnistin käyttää, ennen kuin teet johtopäätöksiä.

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

Mitä käynnistin lupasi tehdä tiedostolle

PIDFile= kertoo palvelunhallinnalle, mistä pääprosessin tunniste luetaan. Hallinta ei kirjoita tuota tiedostoa, mutta se poistaa sammumisen jälkeen henkiin jääneen tiedoston, ja juuri siksi keskeytynyt lopetus voi jättää tiedoston.

Tämä vastuunjako selittää kaksi oiretta, joista ihmiset raportoivat virheinä. Tiedosto, joka ei koskaan ilmesty, tarkoittaa, että daemon tai sen skripti ei saanut sitä kirjoitettua, ei että valvonta on väärin asetettu. Tiedosto, joka selviää pysäytyksestä, tarkoittaa, että sammumispolku ei koskaan valmistunut.

Se selittää myös, miksi nykyiset ohjeet suosittelevat käytännön välttämistä, kun valvonta voi seurata pääprosessia suoraan. Nämä ohjeet eivät ole lupa muuttaa paketoidun yksikön tyyppiä, koska daemonin etualalla, haarautumisessa tai ilmoituksessa käyttäytymisen on vastattava sitä, mitä yksikkö ilmoittaa. Muuta tyyppiä muuttamatta daemonia, niin saat yksikön, joka ilmoittaa virheestä tunnelin ajaessa, tai päinvastoin. Sovita pari tai jätä molemmat. systemd-palvelun viite kuvaa omistuksen jaon.

Puhdas sammuminen vastaan keskeytynyt lopetus

Puhdas pysäytys pyytää daemonia lopettamaan, odottaa sitä ja antaa hallinnan siivota oma kirjanpitonsa. Keskeytynyt lopetus, tapettu prosessi tai uudelleenkäynnistys sammumisen keskellä ohittaa osia tuosta järjestyksestä, ja tiedosto on se, mitä jää. Sen löytäminen kaatumisen jälkeen kertoo, että sammuminen ei valmistunut, ei että jokin kuuntelee.

Vertaa tiedoston aikaleimaa viimeisimpään käynnistykseen ja yksikön viimeisimpään pysäytykseen.

Tarkista sitten elävät todisteet suoraan. VPN-porttiin sidottu socket ja osoitteellinen tunnelirajapinta ovat todiste siitä, että jotain on käynnissä, tavalla, jolla ajonaikaisen hakemiston tekstitiedosto ei koskaan ole. Jos molemmat puuttuvat, mitään ei ole käynnissä, mitä tiedosto väittääkin.

Lopeta tiedoston poistaminen tavan vuoksi

Sen poistaminen on laillinen palautusvaihe, kun olet todennut, että mikään instanssi ei omista sitä ja että käynnistin dokumentoi tämän käyttäytymisen.

Pysyvänä tapana ennen käynnistystä se kumoaa tarkistuksen, jota kierrät. Jos vanhentuneet tiedostot palaavat jokaisen puhtaan pysäytyksen jälkeen, kirjoittaja ja sammumisen elinkaari ovat eri mieltä siitä, kuka polun omistaa, ja tuo erimielisyys on vika, joka kannattaa korjata.

Pidä itsenäinen reitti isäntään, käynnistä yksi instanssi sen normaalilla hallinnalla ja lue ensimmäinen tulos. Seuraava henkilö saa yksikön, joka joko toimii tai selittää itsensä.