OpenVPN säger active (exited)? Hitta instansen du startade

Du kontrollerar tunneln, kör systemctl status openvpn och får active (exited) utan Main PID och med en tom processlista. Den naturliga läsningen är att tjänsten startade och dog, så du öppnar uniten, hittar /bin/true och drar slutsatsen att paketet är trasigt. I Debian-paketet är det tillståndet wrappern som arbetar som designat, och tunneln bor i en av de instans-units som den startar. Den samlade uniten kommer aldrig att berätta vilken instans som byggde den.

Vad active (exited) egentligen betyder på den här uniten

Den paketerade uniten är en engångsuppgift: dess ExecStart är /bin/true, och RemainAfterExit=yes är det som håller en avslutad unit rapporterad som active (exited). Ta bort den direktivet och samma lyckade /bin/true-uppgift slutar i inactive (dead), vilket är precis det tillstånd folk förväntar sig och läser fel i motsatt riktning. Kommandot är bara en platshållare, och uniten rapporterar om arbete som andra units utför. Inget i den ordningen är trasigt, och att ersätta /bin/true ändrar paketeringskontraktet, inte tunneln.

Wrappern delegerar. Den startar de instans-units som paketkonfigurationen eller dess systemd-generator levererar, och därför bevisar en tom processlista ingenting om tunneln. När ingen instans är vald lyckas wrappern ändå och startar ändå ingenting. Tillståndet svarar på om wrappern körde, inte om det finns en tunnel.

Läs de tre raderna i status-utskriften i stället för ordet inom parentes. Loaded namnger unitfilen som systemd läste, Active bär tidsstämpeln för den senaste lyckade körningen, och den saknade Main PID passar en avslutad engångsuppgift. De tre raderna är också sättet att skilja den här wrappern från en tjänst som kraschade en sekund efter start.

Lista unitarna innan du läser status igen

Fråga systemd vad som finns innan du frågar vad som körs. En mall kan vara installerad medan ingen instans är skapad, och bara en skapad unit bär en tunnel. Börja med den inlästa uppsättningen:

systemctl list-units 'openvpn*'

Den listan är vad systemd har läst in i detta ögonblick, och det är det närmaste man kommer en tunnelinventering. Installerade unitfiler svarar på en annan fråga, och den listan visar fortfarande en mall när inget är skapat:

systemctl list-unit-files 'openvpn*'

Läs de två listorna tillsammans, eftersom en mall i den andra och en instans i den första är olika svar. En mall som finns och en instans som körs är inte samma faktum, och bara det andra betyder en tunnel. Paketlayouter varierar också mellan distributioner och OpenVPN-versioner. En äldre openvpn@-mall, ett delat client- och serverpar och en distributionswrapper kan alla vara legitima i sin egen paketering.

Anpassa dig till din maskin i stället för handledningen du hittade. Instansnamnet i någon annans utskrift kan vara office medan ditt är home eller work. Det som överförs är metoden, inte strängen.

Följ instansnamnet till filen den läser

I upstream client-mallen är unitens arbetskatalog /etc/openvpn/client och dess kommando tar %i.conf därifrån, så openvpn-client@office läser /etc/openvpn/client/office.conf. Bekräfta den kopplingen på den installerade uniten i stället för att lita på exemplet, eftersom mallen du har kan vara äldre eller en omskrivning från distributionen:

systemctl cat [email protected]

Läs de drop-in-filer som visas längst ner i den utskriften, eftersom en fil under .d/ kan ändra ExecStart, arbetskatalogen eller konfigurationssökvägen. En profil du laddade ner som office.ovpn är inte filen som instansen öppnar. Den luckan är den vanliga anledningen till att ett fel nämner en sökväg du aldrig har redigerat.

Relativa sökvägar inne i profilen är nästa fälla. Att flytta huvudfilen medan ca-, cert- och key-referenserna förblir relativa byter ett saknad-fil-fel mot ett annat saknad-fil-fel. Den andra pekar på en fil som du var säker på fanns, och därför betyder profilmappen mer än filnamnet.

Starta den och läs sedan journalen för den instansen

Starta instansen du just undersökte, eftersom loggen för den samlade uniten inte kommer att innehålla tunnelns fel. Läs sedan journalen för den här uppstarten och leta i den ordningen efter ett konfigurationsfel, ett filåtkomstfel och ett anslutningsfel, eftersom var och en misslyckas i olika skeden av starten.

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

Start och aktivering är separata beslut: start kör uniten nu, enable ordnar nästa uppstart, och enable --now gör båda i ett steg. daemon-reload läser om unitdefinitioner och startar inte om en körande process och tillämpar inte en redigerad profil. När du har ändrat profilen, starta om instansen, eftersom det är det som läser filen igen.

Sätt inte en andra hanterare på samma tunnel

NetworkManager och OpenVPN 3-sessionshanterarna äger sitt eget anslutningstillstånd, och en systemd-instans bredvid en av dem sätter två ägare på samma tunnel. Symtomet är en tunnel som kommer upp och ersätts sekunder senare, eller en som vägrar att förbli stoppad. Välj den hanterare som din distribution dokumenterar för skrivbordet, och använd systemd medvetet på en server.

Kontrollera om det redan finns en ägare innan du startar en instans. När en skrivbordsapplet visar anslutningen konkurrerar instansen du startar med den i stället för att fullborda den. Inaktivera hanteraren du inte använder i stället för att köra båda och hoppas att ordningen håller. Den konflikten förklarar också journaler där en tunnel etableras och sedan rivs ner av en process du aldrig startade.

Svara på den ursprungliga frågan med instansnamnet, filen den läste och journalraden som misslyckades. OpenVPN:s anteckningar om systemd-integration beskriver mallayouten och filkopplingen som instansnamnet löses igenom.