OpenVPN startet, men skrev ingenting: sjekk log-append først

Du starter OpenVPN fra et skall med en konfigurasjonsfil, og terminalen blir stående helt uten utdata. Ingen banner, ingen feil, ingen ledetekst. Instinktet sier at starten mislyktes, så du starter en ny kopi, deretter en til, og maskinen ender opp med flere halvkonfigurerte instanser. Før noe av dette, sjekk profilen for et direktiv som allerede har omdirigert loggen et annet sted. Stillhet er en egenskap ved konsollen, ikke ved prosessen.

Stillhet har to svært forskjellige forklaringer

Den første er at prosessen kjører fint og skriver til en fil du ikke følger med på. Den andre er at den avsluttet umiddelbart med en feil som er registrert i samme fil.

Begge etterlater en tom terminal, og ett spørsmål skiller dem: finnes det en prosess nå, og hva står i filen den ble bedt om å skrive til. Svar på det før du rører konfigurasjonen igjen. Å starte på nytt for å få utdata er hvordan to instanser ender med å slåss om én tunellenhet og samme port, noe som gir feil som ikke har noe med det opprinnelige problemet å gjøre.

Finn direktivet, og finn deretter prosessen.

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

Finn målet den kjørende prosessen bruker

Les profilen prosessen faktisk ble startet med, ikke den du redigerte. En tjenestestyrt instans laster vanligvis en annen bane og kjører i en annen arbeidskatalog, så et relativt filnavn løses ut et sted du ikke forventet.

Et eksplisitt cd direktiv gjør den forskjellen skarpere, fordi den relative banen flytter seg med katalogbyttet. Hvis du arvet denne konfigurasjonen, kan filen ligge på et sted ingen ville lete nå.

Sammenlign filens endringstid med øyeblikket du startet. En logg fra forrige uke er bevis om forrige uke. Les deretter de siste linjene i filen som endret seg, og behandle det som står der som startmeldingen du har manglet.

log versus log-append: bevis og sletting

log-append legger til det som allerede står i filen. log åpner filen for skriving og avkorter den, så å bytte mellom de to kan slette kjøringen du var i ferd med å lese.

Hvis noen endret direktivet under feilsøking, er det forrige beviset allerede borte, og filstørrelsen vil virke mistenkelig liten. Det er verdt å vite før du sammenligner to kjøringer og konkluderer med at noe endret seg. Slett en logg med vilje, eller behold den, men vit hvilket du gjorde. Bevis du fjernet med vilje er lettere å resonnere om enn bevis du mistet ved uhell.

Ingen av alternativene oppretter manglende overordnede kataloger, og ingen av dem gir tilgang gjennom filsystemtillatelser eller en tjenestesandkasse. En bane som ser riktig ut i konfigurasjonen kan fortsatt være uskrivbar for kontoen daemonen kjører som, og da kan daemonen mislykkes før den får rapportert noe. Sjekk om katalogen finnes og hvem som eier den før du antar at filnavnet er problemet.

Når en tjenesteinnpakning fanger utdata

Under systemd går standardutdata og feil til journalen med mindre et eksplisitt fildirektiv har forrang, og en leverandørinnpakning kan fange dem helt andre steder.

Det er derfor samme profil oppfører seg annerledes fra et skall og fra en unit. Unitens miljø, arbeidskatalog og standardstrømmer er alle forskjellige fra det interaktive skallet ditt. En relativ bane kan løses i én sammenheng og ende ingen steder i den andre. Les unitdefinisjonen når de to er uenige, ikke profilen.

Sammenlign de to startmåtene i stedet for å konkludere med at en av dem er ødelagt. Les unitens kommandolinje og miljøet dens, og les deretter journalen for samme tidsvindu. Hvis innpakningen omdirigerer utdata til sin egen fil, er den filen loggen din nå, og OpenVPN-direktivene er irrelevante for hvor meldingene tok veien.

Øk detaljnivået først når du kan lese det

Å øke detaljnivået før du finner målet gir bare mer tekst på et sted du ikke ser på.

Når du vet hvor utdataene lander, viser et moderat nivå at profilen blir tolket og at tilkoblingen blir forsøkt. To eller tre er nok for et startproblem. Høyere nivåer fortjener plassen sin når feilen er en forhandlingsdetalj, og de gjør også filen raskt større.

Les så den faktiske feilen. En stille terminal beviser ingenting om tunellen kom opp, og feilen som er registrert i filen er den som er verdt å rette.