VPN un proxy servisu izslēgšanas secība sistēmā Linux

Iesprūšana izslēgšanas laikā, kamēr darbojas proxy, reti ir VPN kļūda, pat ja VPN ir pēdējais, kas redzams ekrānā. Lietojumprogrammas aiz proxy joprojām gaida ceļu, kas drīz pazudīs, un vienība, kurai pieder tunelis, vēl nav lūgta to aizvērt. Tas, kas izskatās pēc lēna servisa, parasti ir secības problēma. Secības sakārtošana atrisina vairāk šādu gadījumu nekā jebkura taimauta maiņa.

Virzieties uz āru apgrieztā secībā: vispirms patērētāji, tad proxy, tad tunelis — katru aptur komponente, kas to sāka.

Sastādiet vienību sarakstu, pirms kaut ko apturat

Pierakstiet lietojumprogrammas vienību, proxy vienību un VPN īpašnieku, kas iesaistīti parastā palaišanā. Pievienojiet jebkuru resolveri vai palīgkomponenti ar savu aizvēršanu, jo tieši tos aizmirst divos naktī. Bez šī saraksta pirmā ierakstītā apturēšanas komanda upuri izvēlēsies nejauši.

Nosaukumi ir vājš pierādījums. Lietotāja proxy, sistēmas proxy un citas konta tunelis var dalīt vienu nosaukumu, bet to dzīves cikli ir pilnīgi nesaistīti.

Vispirms pabeidziet darbu, tad apturiet patērētāju

Plānota apturēšana sākas ar lietojumprogrammu: ļaujiet tai pabeigt vai atcelt savus pieprasījumus, pēc tam apturiet proxy caur tā servisa vienību. Ja lietojumprogrammai jāturpina darboties pēc tuneļa pazušanas, iekārtojiet to apzināti, nevis atstājiet to piesaistītu maršrutam, kas drīz pazudīs.

Pieprasījumi, kas apturēšanas laikā bija lidojumā, pieder ierakstam, jo tieši no turienes nāk atkārtojumu vētra nākamajā palaišanā.

ExecStop un ExecStopPost ir dažādi instrumenti

ExecStop= — tā ir sinhronā apturēšanas operācija; ExecStopPost= — tā ir tīrīšana, kas tiek izpildīta arī pēc neveiksmīgas palaišanas. Apturēšanas komanda, kas tikai nosūta procesam signālu un atgriežas, ļauj systemd virzīties tālāk, kamēr patērētājs vēl izvada datus. Viss, kam jānotiek jebkurā gadījumā, pieder pēc-apturēšanas variantam, un viss, kam jābloķē apturēšana, pieder sinhronajam. Pārbaudiet spēkā esošo vienību un tās drop-in failus, nevis rediģējiet pakotnes failu uz vietas.

Atkarību grafs sakārto apturēšanas uzdevumus. Tas nepārvērš asinhronu skriptu sinhronā un neliek attālinātai lietojumprogrammai apstiprināt savus datus.

Ierobežojiet apturēšanu un ziniet, cik šis ierobežojums maksā

TimeoutStopSec= ierobežo gan apturēšanas komandu, gan paša servisa izbeigšanu, un, kad limits beidzas, systemd pāriet uz piespiedu nogalināšanu. Izvēlieties vērtību pēc lietojumprogrammas reālās izvades uzvedības un pierakstiet, kas var tikt zaudēts, kad limits iestāsies. Skaitlis, kas izvēlēts tāpēc, ka mašīnai jāizslēdzas ātrāk, ir datu zaudēšanas iestatījums citā nosaukumā.

Kad apturēšana joprojām ir lēna, fiksējiet vienību, tās pakārtotos procesus, žurnāla intervālu un taimauta rezultātu. Visu taimautu saīsināšana vai ķeršanās pie plašas nogalināšanas ir veids, kā tīras apturēšanas pārvēršas bojātā stāvoklī nākamajā palaišanā.

Atvienojieties caur īpašnieku, pēc tam pārbaudiet trīs gadījumus

Kad patērētāji ir apturēti, lūdziet pārvaldnieku, kuram pieder tunelis, atvienoties: systemd instanci, aktīvo NetworkManager savienojumu vai piegādātāja servisu. Nesaistīta OpenVPN procesa nogalināšana ne vienmēr noņem sesiju, kas nodrošināja maršrutu, un proxy ar restartēšanas politiku var no jauna izveidot pieprasījumu, kamēr jūs izjaucat ceļu. Saskaņojiet šo politiku ar plānoto apturēšanu pirms sākšanas.

Pārbaudiet parastu apturēšanu, apturēšanu ar aktīvu pieprasījumu un apturēšanu, kurā tunelis neizdodas pirmais. Atkārtojama secība ar termiņu ir labāka par ātru izslēgšanu, kas nostrādā vienu reizi.