openvpn --errors-to-stderr er en startindstilling, ikke en fejl

En kommandolinje, der indeholder --errors-to-stderr ligner en klage, men er ikke en. Ordet hører til et indstillingsnavn, ligesom et logfilnavn ikke siger noget om, hvad filen indeholder. Før du ændrer nogen konfiguration, skal du fastslå, hvad du faktisk læser.

Beslutningen har tre grene: linjen er selve starten, linjen er output, som programmet har skrevet, eller linjen er tekst, som en wrapper har gentaget, før VPN startede. Hver gren peger på et forskelligt sted at kigge, og kun én af dem er VPN'ens egen besked.

Et indstillingsnavn er ikke en statusmeddelelse

For Community OpenVPN, --errors-to-stderr sender fejloutput til standardfejl i stedet for standardoutput. Det er et valg af strøm, ikke et filter for alvor, og det skaber ikke en fejl. Et senere --log eller --log-append kan omdirigere de samme meddelelser til en fil, og derfor afhænger flagets virkning af resten af kommandoen. Logreferencen hos kilden fastlægger den rækkefølge.

Så flagets tilstedeværelse fortæller, hvor fejlene ville havne. Det fortæller ikke, at der er opstået en.

Startlinje eller procesoutput

Begynd med at spørge, hvem der skrev teksten. En serviceenhed, en applikationspakke eller en shell-wrapper gentager ofte hele argv, før VPN-processen skriver noget. Den gentagelse kan ikke skelnes fra en statuslinje, hvis du kun ser et uddrag.

Hvis linjen kom fra wrapperen, har VPN ikke kørt endnu og har intet at rapportere. Se længere nede i outputtet efter den første meddelelse med et tidsstempel eller et undersystemnavn.

Hvis linjen kom fra VPN-processen, er det stadig bare kaldet. OpenVPN udskriver ikke sin egen kommandolinje som en fejl, og de meddelelser, der betyder noget, følger efter.

Find processen og dens resultat

Fastslå, om processen stadig kører. En klient, der er oppe og prøver igen, ser meget anderledes ud end en, der afsluttede med det samme, og den samme kommandolinje står foran begge.

Læs derefter resultatet gennem den komponent, der ejer processen. Under systemd er det enhedens journal; i en desktopapp er det appens egen log eller konsol. Exitstatussen plus de sidste meddelelser besvarer det spørgsmål, som indstillingsnavnet kun antyder.

En konfigurationsparsefejl, en manglende fil, en afvist legitimationsoplysning og en peer-timeout er fire forskellige hændelser. De ankommer på samme strøm. De kræver fire forskellige rettelser. Afgør, hvilken du har, før du rører profilen, og citer den præcise meddelelse, når du beder om hjælp.

Hvornår flaget fortjener sin plads

Flaget fortjener sin plads, når stdout bærer data, og fejl ikke må forurene det, eller når en wrapper fanger de to strømme hver for sig. I en forgrundssession i en terminal lander begge strømme foran dig. I så fald ændrer sondringen sjældent, hvad du gør.

Behold det, hvis det omkringliggende script afhænger af opdelingen. At fjerne det, fordi navnet ser alarmerende ud, ændrer, hvor meddelelser vises, og retter intet andet.

Hvad du ikke skal ændre

Behandl ikke indstillingen som et reparationsskridt. At slette den kan ikke rette et certifikat, en rute eller en godkendelsesfejl.

Hvis kaldet indeholder --config stdin, bliver konfigurationen ført ind via standardinput. Det er en særskilt beslutning om, hvordan filen leveres. Ændr én ting ad gangen, og læs den faktiske meddelelse igen, før du ændrer den anden.