OpenVPN startade men skrev ingenting: kontrollera log-append först

Du startar OpenVPN från ett skal med en konfigurationsfil, och terminalen står bara där utan någon utdata alls. Ingen banner, inget fel, ingen prompt. Instinkten säger att starten misslyckades, så du startar ännu en kopia, sedan en till, och maskinen hamnar med flera halvkonfigurerade instanser. Innan allt det, kontrollera profilen efter ett direktiv som redan har omdirigerat loggen någon annanstans. Tystnad är en egenskap hos konsolen, inte hos processen.

Tystnad har två mycket olika förklaringar

Den första är att processen körs som den ska och skriver till en fil som du inte bevakar. Den andra är att den avslutades direkt med ett fel som registrerats i samma fil.

Båda lämnar en tom terminal, och en fråga skiljer dem: finns det en process nu, och vad står i filen som den blev tillsagd att skriva till. Svara på det innan du rör konfigurationen igen. Att starta om för att få utdata är hur två instanser börjar slåss om en enda tunneenhet och samma port, vilket ger fel som inte har något med det ursprungliga problemet att göra.

Hitta direktivet och hitta sedan processen.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Hitta målet som den körande processen använder

Läs profilen som processen faktiskt startades med, inte den du redigerade. En tjänstestyrd instans läser vanligtvis in en annan sökväg och kör i en annan arbetskatalog, så ett relativt filnamn löses upp någonstans där du inte förväntade dig.

Ett uttryckligt cd direktiv gör skillnaden skarpare, eftersom den relativa sökvägen flyttar med katalogbytet. Om du ärvde den här konfigurationen kan filen ligga på en plats där ingen skulle leta nu.

Jämför filens ändringstid med ögonblicket då du startade. En logg från förra veckan är bevis om förra veckan. Läs sedan de sista raderna i filen som ändrades, och behandla det som står där som startmeddelandet du har saknat.

log kontra log-append: bevis och utplåning

log-append lägger till det som redan står i filen. log öppnar filen för skrivning och kortar av den, så att växla mellan de två kan radera körningen du var på väg att läsa.

Om någon ändrade direktivet under felsökningen är det tidigare beviset redan borta och filstorleken kommer att verka misstänkt liten. Det är värt att veta innan du jämför två körningar och drar slutsatsen att något har ändrats. Radera en logg med avsikt eller behåll den, men vet vilket du gjorde. Bevis som du tog bort medvetet är lättare att resonera om än bevis som du tappade av misstag.

Inget av alternativen skapar saknade överordnade kataloger, och ingen av dem ger åtkomst via filsystemets behörigheter eller en tjänstesandlåda. En sökväg som ser korrekt ut i konfigurationen kan fortfarande vara oskrivbar för kontot som daemonen körs som, och då kan daemonen misslyckas innan den hinner rapportera något. Kontrollera att katalogen finns och vem som äger den innan du antar att filnamnet är problemet.

När ett tjänsteomslag fångar utdata

Under systemd går standardutdata och fel till journalen om inte ett uttryckligt fildirektiv har företräde, och ett leverantörsomslag kan fånga dem någon helt annanstans.

Det är därför samma profil beter sig annorlunda från ett skal och från en unit. Unitens miljö, dess arbetskatalog och dess standardströmmar skiljer sig alla från ditt interaktiva skal. En relativ sökväg kan lösas upp i en kontext och inte landa någonstans i den andra. Läs unitdefinitionen när de två inte är överens, inte profilen.

Jämför de två startuppläggen i stället för att dra slutsatsen att ett av dem är trasigt. Läs unitens kommandorad och dess miljö, och läs sedan journalen för samma tidsfönster. Om omslaget omdirigerar utdata till sin egen fil är den filen din logg nu, och OpenVPN-direktiven är irrelevanta för vart meddelandena tog vägen.

Höj detaljnivån först när du kan läsa den

Att höja detaljnivån innan du hittar målet ger bara mer text på en plats du inte tittar på.

När du vet var utdata landar visar en måttlig nivå att profilen tolkas och att anslutningen försöks. Två eller tre räcker för ett startproblem. Högre nivåer förtjänar sin plats när felet är en förhandlingsdetalj, och de gör också filen snabbt större.

Läs sedan det faktiska felet. En tyst terminal bevisar ingenting om huruvida tunneln kom upp, och felet som registrerats i filen är det som är värt att åtgärda.