Soubor PID existuje, tunel žádný: běžel OpenVPN vůbec někdy?
Zbytkový soubor PID nic neříká o tom, zda tunel běží. Než ho smažete, zkontrolujte službu, čas spuštění procesu a smlouvu spouštěče.
Když spouštěč odmítne nastartovat OpenVPN, protože soubor PID už existuje, přirozené čtení je, že někde běží tunel. Takové čtení je dost často chybné na to, aby se vyplatilo ho před smazáním čehokoli ověřit. Soubor v běhovém adresáři je účetnictví a účetnictví přežívá pády, restarty a přerušená vypnutí, po kterých nezůstal žádný proces. Případ rozhodují dvě otázky: existuje živý proces a patří ten proces této instanci.
Začněte službou, ne souborem
Odmítnutí obvykle přichází od spouštěče, ne od samotného OpenVPN. Přečte cestu, najde tam něco a zastaví se dřív, než rozparsuje konfiguraci. První otázka se tedy týká smlouvy spouštěče, ne tunelu.
Přečtěte si unit nebo skript, který zprávu vypsal, a všimněte si tří věcí: cesty, kterou kontroluje, typu služby, který deklaruje, a zda vůbec odpovídá za zápis souboru. Moderní unit může používat prostý nebo notify dohled a souboru PID se nikdy nedotknout, zatímco starší init skript si ho může vytvořit sám. Zkopírování kontroly z jednoho modelu do druhého vytváří přesně tento druh odmítnutí. Zjistěte, který model se používá, než cokoli vyložíte.
Teprve pak se otázka změní na to, zda instance skutečně běží.
Ověřte, zda tento identifikátor patří vaší instanci
Číslo v souboru dokazuje, že bylo zapsáno číslo. Nedokazuje, že proces s tímto identifikátorem existuje právě teď, a rozhodně nedokazuje, že proces je váš, protože identifikátory se po restartu znovu používají.
Porovnejte čas spuštění procesu s časovým razítkem souboru, spustitelný soubor s příkazem unitu a členství ve službě s názvem unitu. Neshoda v kterémkoli ze tří znamená, že se díváte na účetnictví, ne na tunel.
Na hostiteli s kontejnery nebo několika jmennými prostory může mít identifikátor smysl v jednom pohledu a v jiném chybět. To, že proces nevidíte, také není důkazem, že neexistuje, pokud ho váš účet nemůže prozkoumat. Ověřujte z kontextu, který spouštěč používá, než vyvodíte závěry.
systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"Co spouštěč slíbil se souborem udělat
PIDFile= říká správci služeb, odkud má číst identifikátor hlavního procesu. Správce ten soubor nepíše, ale odstraňuje ten, který po vypnutí zůstal, a právě proto může přerušený odchod zanechat soubor.
Toto rozdělení odpovědnosti vysvětluje dva příznaky, které lidé hlásí jako chyby. Soubor, který se nikdy neobjeví, znamená, že ho démon nebo jeho skript nedokázali zapsat, ne že dohled je špatně nastavený. Soubor, který přežije zastavení, znamená, že cesta vypnutí nikdy neskončila.
Vysvětluje to také, proč současné pokyny doporučují vyhnout se této konvenci, když dohled umí sledovat hlavní proces přímo. Tyto pokyny nejsou svolením měnit typ zabaleného unitu, protože chování démona v popředí, při větvení nebo při notifikaci musí odpovídat tomu, co unit deklaruje. Změňte typ bez změny démona a dostanete unit, který hlásí selhání, zatímco tunel běží, nebo naopak. Spárujte obojí, nebo nechte být obojí. Referenční příručka služby systemd popisuje rozdělení vlastnictví.
Čisté vypnutí versus přerušený odchod
Čisté zastavení požádá démona, aby skončil, počká na něj a nechá správce uklidit jeho vlastní účetnictví. Přerušený odchod, zabitý proces nebo restart uprostřed vypínání přeskočí části tohoto sledu a soubor je to, co zůstane. Nález souboru po pádu vám říká, že vypínání nedoběhlo, ne že něco poslouchá.
Porovnejte časové razítko souboru s posledním bootem a s posledním zastavením unitu.
Potom zkontrolujte živé důkazy přímo. Socket navázaný na port VPN a tunelové rozhraní s adresou jsou důkazem, že něco běží, způsobem, jakým textový soubor v běhovém adresáři nikdy není. Pokud chybí obojí, nic neběží, ať soubor tvrdí cokoli.
Přestaňte soubor mazat ze zvyku
Smazání je legitimní krok obnovy poté, co jste zjistili, že ho žádná instance nevlastní a že spouštěč toto chování dokumentuje.
Jako trvalý zvyk před startem to maže kontrolu, kterou obcházíte. Pokud se zastaralé soubory vracejí po každém čistém zastavení, zapisovatel a životní cyklus vypínání se neshodují na tom, kdo cestu vlastní, a ta neshoda je chyba, kterou stojí za to opravit.
Udržujte si nezávislou cestu do hostitele, spusťte jednu instanci jejím běžným správcem a přečtěte první výsledek. Příští člověk dostane unit, který buď funguje, nebo se vysvětlí.