PID fails ir, tuneļa nav: vai OpenVPN kādreiz darbojās?

Kad palaidējs atsakās palaist OpenVPN, jo PID fails jau pastāv, dabiskā lasīšana ir tāda, ka kaut kur darbojas tunelis. Šī lasīšana ir pietiekami bieži nepareiza, lai to būtu vērts pārbaudīt pirms kaut kā dzēšanas. Fails izpildes direktorijā ir uzskaite, un uzskaite pārdzīvo avārijas, pārstartēšanas un pārtrauktas izslēgšanas, kas neatsūtīja procesu. Lēmumu pieņem divi jautājumi: vai ir dzīvs process un vai šis process pieder šai instancei.

Sāciet ar servisu, nevis ar failu

Atteikums parasti nāk no palaidēja, nevis no paša OpenVPN. Tas nolasa ceļu, atrod tur kaut ko un apstājas pirms konfigurācijas analīzes. Tāpēc pirmais jautājums ir par palaidēja līgumu, nevis par tuneli.

Izlasiet vienību vai skriptu, kas izdrukāja ziņojumu, un ievērojiet trīs lietas: pārbaudīto ceļu, deklarēto servisa tipu un to, vai tas vispār ir atbildīgs par faila rakstīšanu. Mūsdienu vienība var izmantot vienkāršu vai paziņojumu uzraudzību un nekad neaiztikt PID failu, savukārt vecāks init skripts var izveidot to pats. Pārbaudes kopēšana no viena modeļa uz otru rada tieši šādu atteikumu. Noskaidrojiet, kurš modelis tiek izmantots, pirms kaut ko interpretējat.

Tikai tad jautājums kļūst par to, vai instance tiešām darbojas.

Pārbaudiet, vai šis identifikators pieder jūsu instancei

Skaitlis failā pierāda, ka skaitlis tika ierakstīts. Tas nepierāda, ka process ar šo identifikatoru pastāv tagad, un noteikti nepierāda, ka process ir jūsējais, jo identifikatori pēc pārstartēšanas tiek izmantoti atkārtoti.

Salīdziniet procesa sākuma laiku ar faila laika zīmi, izpildāmo failu ar vienības komandu un dalību servisā ar vienības nosaukumu. Neatbilstība kādā no trim nozīmē, ka jūs skatāties uz uzskaiti, nevis tuneli.

Uz resursdatora, kurā darbojas konteineri vai vairākas nosaukumu telpas, identifikators var būt jēgpilns vienā skatā un iztrūkt citā. Procesa neredzēšana arī nav pierādījums, ka tas neeksistē, ja jūsu konts to nevar pārbaudīt. Pārbaudiet no konteksta, ko izmanto palaidējs, pirms izdarāt secinājumus.

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

Ko palaidējs apsolīja darīt ar failu

PIDFile= servisa pārvaldniekam norāda, no kurienes lasīt galvenā procesa identifikatoru. Pārvaldnieks šo failu neraksta, bet pēc izslēgšanas noņem pāri palikušo, un tieši tāpēc pārtraukta iziešana var atstāt failu.

Šis atbildības sadalījums izskaidro divus simptomus, par kuriem cilvēki ziņo kā par kļūdām. Fails, kas nekad neparādās, nozīmē, ka dēmons vai tā skripts nespēja to uzrakstīt, nevis to, ka uzraudzība ir nepareizi konfigurēta. Fails, kas pārdzīvo apstādināšanu, nozīmē, ka izslēgšanas ceļš nekad netika pabeigts.

Tas arī izskaidro, kāpēc pašreizējās vadlīnijas iesaka izvairīties no šīs konvencijas, kad uzraudzība var tieši sekot galvenajam procesam. Šīs vadlīnijas nav atļauja mainīt iepakotās vienības tipu, jo dēmona uzvedībai priekšplānā, zarošanā vai paziņošanā jāatbilst tam, ko vienība deklarē. Nomainiet tipu, nemainot dēmonu, un jūs iegūsit vienību, kas ziņo par neveiksmi, kamēr tunelis darbojas, vai otrādi. Saskaņojiet pāri vai atstājiet abus. systemd servisa uzziņa apraksta īpašumtiesību sadalījumu.

Tīra izslēgšana pret pārtrauktu iziešanu

Tīra apstādināšana lūdz dēmonu iziet, nogaida un ļauj pārvaldniekam sakārtot savu uzskaiti. Pārtraukta iziešana, nogalināts process vai pārstartēšana izslēgšanas vidū izlaiž daļas no šīs secības, un fails ir tas, kas paliek. Tā atrašana pēc avārijas pārstāsta, ka izslēgšana netika pabeigta, nevis ka kaut kas klausās.

Salīdziniet faila laika zīmi ar pēdējo palaišanu un ar vienības pēdējo apstādināšanu.

Pēc tam tieši pārbaudiet dzīvos pierādījumus. Ar VPN portu saistīts socket un tuneļa saskarne ar adresi ir pierādījums, ka kaut kas darbojas, tā, kā teksta fails izpildes direktorijā nekad nav. Ja abu nav, nekas nedarbojas, ko vien fails apgalvotu.

Pārtrauciet dzēst failu ieraduma dēļ

Tā dzēšana ir likumīgs atjaunošanas solis pēc tam, kad esat noskaidrojis, ka neviena instance to neīpašo un ka palaidējs dokumentē šo uzvedību.

Kā pastāvīgs ieradums pirms palaišanas tas iznīcina pārbaudi, kuru jūs apiet. Ja novecojuši faili atgriežas pēc katras tīrās apstādināšanas, rakstītājs un izslēgšanas dzīves cikls nepiekrīt, kam pieder ceļš, un šī nesaskaņa ir kļūda, ko ir vērts labot.

Saglabājiet neatkarīgu piekļuvi resursdatoram, palaidiet vienu instanci ar tās parasto pārvaldnieku un izlasiet pirmo rezultātu. Nākamais cilvēks saņem vienību, kas vai nu darbojas, vai paskaidro sevi.