OpenVPN sê active (exited)? Vind die instansie wat jy begin het

Jy kyk na die tonnel, voer systemctl status openvpn uit en kry active (exited) sonder 'n Main PID en met 'n leë prosesselys. Die natuurlike lees is dat die diens begin en gesterf het, so jy maak die eenheid oop, vind /bin/true en maak die gevolgtrekking dat die pakket stukkend is. Op die Debian-verpakking is daardie toestand die omhulsel wat werk soos ontwerp, en die tonnel woon in een van die instansie-eenhede wat dit begin. Die saamgestelde eenheid sal jou nooit vertel watter instansie dit gebou het nie.

Wat active (exited) op hierdie eenheid werklik beteken

Die verpakte eenheid is 'n eenmalige taak: sy ExecStart is /bin/true, en RemainAfterExit=yes is wat 'n voltooide eenheid as active (exited) laat rapporteer. Neem daardie richtlijn weg en dieselfde suksesvolle /bin/true-eenmalige taak eindig in inactive (dead), wat presies die toestand is wat mense verwag en in die ander rigting verkeerd lees. Die opdrag is 'n plekhouer, en die eenheid rapporteer oor werk wat ander eenhede verrig. Niks aan daardie reëling is stukkend nie, en om /bin/true te vervang verander die verpakkingskontrak eerder as die tonnel.

Die omhulsel delegeer. Dit begin die eenhede per instansie wat die pakketkonfigurasie of sy systemd-generator verskaf, en daarom bewys 'n leë prosesselys niks oor die tonnel nie. Wanneer geen instansie gekies is nie, slaag die omhulsel steeds en begin steeds niks. Die toestand antwoord of die omhulsel geloop het, nie of 'n tonnel bestaan nie.

Lees die drie reëls van die statusuitvoer eerder as die woord tussen hakies. Loaded noem die eenheidlêer wat systemd gelees het, Active dra die tydstempel van die laaste suksesvolle loop, en die afwesige Main PID pas by 'n eenmalige taak wat klaar is. Daardie drie reëls is ook hoe jy hierdie omhulsel onderskei van 'n diens wat 'n sekonde ná die begin in duie gestort het.

Lys die eenhede voordat jy die status weer lees

Vra systemd wat bestaan voordat jy vra wat loop. 'n Sjabloon kan geïnstalleer wees terwyl geen instansie geïnstantieer is nie, en net 'n geïnstantieerde eenheid dra 'n tonnel. Begin met die gelaaide stel:

systemctl list-units 'openvpn*'

Daardie lys is wat systemd op hierdie oomblik gelaai het, wat die naaste ding aan 'n tonnel-inventaris is. Geïnstalleerde eenheidlêers antwoord 'n ander vraag, en daardie lys wys steeds 'n sjabloon wanneer niks geïnstantieer is:

systemctl list-unit-files 'openvpn*'

Lees die twee lyste saam, want 'n sjabloon in die tweede en 'n instansie in die eerste is verskillende antwoorde. 'n Sjabloon wat bestaan en 'n instansie wat loop is nie dieselfde feit nie, en net die tweede een beteken 'n tonnel. Pakketuitlegte verskil ook tussen verspreidings en OpenVPN-weergawes. 'n Ouer openvpn@-sjabloon, 'n gesplete kliënt- en bedienerpaar en 'n verspreidingsomhulsel kan almal op hul eie verpakking wettig wees.

Pas jou masjien aan eerder as die tutoriaal wat jy gevind het. Die instansienaam in iemand anders se uitvoer kan office wees terwyl joune home of work is. Wat oorgedra word, is die metode, nie die string nie.

Volg die instansienaam na die lêer wat dit lees

Op die opstroom-kliëntsjabloon is die eenheid se werkgids /etc/openvpn/client en sy opdrag neem %i.conf daarvandaan, so openvpn-client@office lees /etc/openvpn/client/office.conf. Bevestig daardie kartering op die geïnstalleerde eenheid eerder as om die voorbeeld te vertrou, want die sjabloon wat jy het kan ouer wees of 'n verspreidingsherberwerking wees:

systemctl cat [email protected]

Lees die drop-ins wat onderaan daardie uitvoer verskyn, want 'n lêer onder .d/ kan ExecStart, die werkgids of die konfigurasiepad verander. 'n Profiel wat jy as office.ovpn afgelaai het, is nie die lêer wat die instansie oopmaak. Daardie gaping is die gewone rede waarom 'n fout 'n pad noem wat jy nooit geredigeer het nie.

Relatiewe paaie binne die profiel is die volgende lokval. Om die hoof-lêer te skuif terwyl ca-, cert- en key-verwysings relatief bly, ruil 'n ontbrekende-lêer-fout vir 'n ander ontbrekende-lêer-fout. Die tweede een wys na 'n lêer waarvan jy seker was dat dit bestaan, en daarom maak die profielgids meer saak as die lêernaam.

Begin dit, en lees dan daardie instansie se joernaal

Begin die instansie wat jy pas ondersoek het, want die saamgestelde eenheid se log sal nie die tonnel se foute bevat nie. Lees dan die joernaal vir hierdie selflaai en soek in daardie volgorde na 'n konfigurasiefout, 'n lêertoegangsfout en 'n verbindingsfout, want elkeen faal op 'n ander stadium van die selflaai.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Begin en aktiveer is aparte besluite: start voer die eenheid nou uit, enable reël die volgende selflaai, en enable --now doen albei in een stap. daemon-reload herlees eenheiddefinisies en herbegin nie 'n lopende proses nie en pas nie 'n geredigeerde profiel toe nie. Nadat jy die profiel verander het, herbegin die instansie, want dit is wat die lêer herlees.

Moenie 'n tweede bestuurder op dieselfde tonnel plaas nie

NetworkManager en die OpenVPN 3-sessiebestuurders besit hul eie verbindingstoestand, en 'n systemd-instansie langs een van hulle plaas twee eienaars op dieselfde tonnel. Die simptoom is 'n tonnel wat opkom en sekondes later vervang word, of een wat weier om gestop te bly. Kies die bestuurder wat jou verspreiding vir die lessenaar dokumenteer, en gebruik systemd doelbewus op 'n bediener.

Kontroleer vir 'n bestaande eienaar voordat jy 'n instansie begin. Wanneer 'n lessenaar-applet die verbinding wys, ding die instansie wat jy begin daarmee mee eerder as om dit te voltooi. Deaktiveer die bestuurder wat jy nie gebruik nie in plaas daarvan om albei te laat loop en te hoop die volgorde hou. Daardie konflik verduidelik ook joernale waar 'n tonnel opgebou en dan afgebreek word deur 'n proses wat jy nooit begin het nie.

Antwoord die oorspronklike vraag met die instansienaam, die lêer wat dit gelees het en die joernaalreël wat gefaal het. systemd-integrasienotas beskryf die sjabloonuitleg en die lêerkartering waardeur die instansienaam opgelos word.