OpenVPN gestart maar niets afgedrukt: controleer eerst log-append

Je start OpenVPN vanuit een shell met een configuratiebestand, en de terminal blijft daar staan zonder enige uitvoer. Geen banner, geen fout, geen prompt. Het instinct zegt dat de start is mislukt, dus je start nog een kopie, dan nog een, en de machine eindigt met meerdere half geconfigureerde instanties. Controleer voordat je dat allemaal doet het profiel op een richtlijn die de log al ergens anders heen heeft gestuurd. Stilte is een eigenschap van de console, niet van het proces.

Stilte heeft twee heel verschillende verklaringen

De eerste is dat het proces gewoon draait en schrijft naar een bestand dat je niet volgt. De tweede is dat het onmiddellijk stopte met een fout die in datzelfde bestand is vastgelegd.

Beide laten een lege terminal achter, en één vraag scheidt ze: is er nu een proces, en wat staat er in het bestand waarnaar het moest schrijven. Beantwoord dat voordat je de configuratie opnieuw aanraakt. Opnieuw starten om uitvoer te krijgen is hoe twee instanties ruzie krijgen over één tunnelapparaat en dezelfde poort, wat fouten oplevert die niets met het oorspronkelijke probleem te maken hebben.

Vind de richtlijn en vind daarna het proces.

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

Vind de bestemming die het draaiende proces gebruikt

Lees het profiel waarmee het proces daadwerkelijk is gestart, niet het profiel dat je hebt bewerkt. Een door een service beheerde instantie laadt meestal een ander pad en draait in een andere werkmap, dus een relatieve bestandsnaam wordt ergens opgelost waar je het niet verwachtte.

Een expliciete cd richtlijn maakt dat onderscheid scherper, omdat het relatieve pad meebeweegt met de mapwisseling. Als je deze configuratie hebt geërfd, kan het bestand op een plek staan waar nu niemand zou zoeken.

Vergelijk de wijzigingstijd van het bestand met het moment waarop je startte. Een log van vorige week is bewijs over vorige week. Lees daarna de laatste regels van het bestand dat is gewijzigd, en beschouw wat daar staat als het opstartbericht dat je hebt gemist.

log versus log-append: bewijs en uitwissing

log-append voegt toe aan wat er al in het bestand staat. log opent het bestand om te schrijven en kort het in, dus wisselen tussen de twee kan de run verwijderen die je wilde lezen.

Als iemand de richtlijn tijdens het debuggen heeft gewijzigd, is het eerdere bewijs al weg en ziet de bestandsgrootte er verdacht klein uit. Dat is goed om te weten voordat je twee runs vergelijkt en concludeert dat er iets is veranderd. Verwijder een log bewust of bewaar hem, maar weet welke van de twee je deed. Bewijs dat je opzettelijk hebt weggehaald is makkelijker te beredeneren dan bewijs dat je per ongeluk kwijt bent.

Geen van beide opties maakt ontbrekende bovenliggende mappen aan, en geen van beide geeft toegang via bestandssysteemrechten of een service-sandbox. Een pad dat er in de configuratie correct uitziet, kan nog steeds onschrijfbaar zijn voor het account waaronder de daemon draait, en dan kan de daemon mislukken voordat hij iets kan melden. Controleer of de map bestaat en wie de eigenaar is voordat je aanneemt dat de bestandsnaam het probleem is.

Wanneer een service-wrapper de uitvoer opvangt

Onder systemd gaan standaarduitvoer en fouten naar het journaal, tenzij een expliciete bestandsrichtlijn voorrang heeft, en een leverancierswrapper kan ze heel ergens anders opvangen.

Daarom gedraagt hetzelfde profiel zich anders vanuit een shell en vanuit een unit. De omgeving van de unit, de werkmap en de standaardstromen verschillen allemaal van je interactieve shell. Een relatief pad kan in de ene context worden opgelost en in de andere nergens landen. Lees de unitdefinitie als de twee het oneens zijn, niet het profiel.

Vergelijk de twee startopstellingen in plaats van te concluderen dat een ervan kapot is. Lees de commandoregel van de unit en de omgeving ervan, en lees daarna het journaal voor hetzelfde tijdvenster. Als de wrapper de uitvoer naar zijn eigen bestand omleidt, is dat bestand nu je log, en zijn de OpenVPN-richtlijnen irrelevant voor waar de berichten heen gingen.

Verhoog de uitgebreidheid pas als je die kunt lezen

Uitgebreidheid verhogen voordat je de bestemming vindt, levert alleen meer tekst op een plek waar je niet kijkt.

Zodra je weet waar de uitvoer landt, laat een gematigd niveau zien dat het profiel wordt geparseerd en de verbinding wordt geprobeerd. Twee of drie is genoeg voor een opstartprobleem. Hogere niveaus verdienen hun plek wanneer de fout een onderhandelingsdetail is, en ze laten het bestand ook snel groeien.

Lees dan de werkelijke fout. Een stille terminal bewijst niets over of de tunnel omhoogkwam, en de fout die in het bestand is vastgelegd is degene die het waard is om te repareren.