openvpn --errors-to-stderr est une option de lancement, pas une erreur

Une ligne de commande contenant --errors-to-stderr ressemble à une plainte et n’en est pas une. Le mot appartient au nom d’une option, tout comme le nom d’un fichier journal ne dit rien de son contenu. Avant de modifier une configuration, établissez ce que vous lisez réellement.

La décision a trois branches : la ligne est le lancement lui-même, la ligne est une sortie imprimée par le programme, ou la ligne est un texte qu’un enrobage a répété avant le démarrage du VPN. Chaque branche indique un endroit différent où regarder, et une seule est le message propre au VPN.

Le nom d’une option n’est pas un message d’état

Pour Community OpenVPN, --errors-to-stderr achemine la sortie d’erreur vers l’erreur standard au lieu de la sortie standard. C’est un choix de flux, non un filtre de gravité, et cela ne crée aucune erreur. Un --log ou un --log-append ultérieur peut rediriger les mêmes messages vers un fichier, ce qui explique pourquoi l’effet de l’indicateur dépend du reste de la commande. La référence de journalisation d’amont définit cet ordre.

La présence de l’indicateur vous dit donc où iraient les erreurs. Elle ne vous dit pas qu’une erreur a eu lieu.

Ligne de lancement ou sortie du processus

Commencez par demander qui a imprimé le texte. Une unité de service, un paquet d’application ou un enrobage de shell répètent souvent l’argv complet avant que le processus VPN n’écrive quoi que ce soit. Cet écho est impossible à distinguer d’une ligne d’état si vous n’en voyez qu’un fragment.

Si la ligne vient de l’enrobage, le VPN n’a pas encore tourné et n’a rien à signaler. Cherchez plus bas dans la sortie le premier message portant un horodatage ou un nom de sous-système.

Si la ligne vient du processus VPN, ce n’est encore que l’appel. OpenVPN n’imprime pas sa propre ligne de commande comme une erreur, et les messages qui comptent viennent ensuite.

Trouver le processus et son résultat

Établissez si le processus tourne encore. Un client actif qui réessaie est très différent d’un client qui s’est arrêté immédiatement, et la même ligne de commande précède les deux.

Lisez ensuite le résultat via le composant qui possède le processus. Sous systemd, c’est le journal de l’unité ; dans une application de bureau, c’est le journal ou la console de l’application. Le code de sortie et les derniers messages répondent à la question que le nom de l’option ne fait qu’évoquer.

Une erreur d’analyse de configuration, un fichier manquant, un identifiant rejeté et un délai d’attente du pair sont quatre événements différents. Ils arrivent sur le même flux. Ils demandent quatre correctifs différents. Décidez lequel vous avez avant de toucher au profil, et citez le message exact lorsque vous demandez de l’aide.

Quand l’indicateur mérite sa place

L’indicateur mérite sa place lorsque la sortie standard transporte des données et que les erreurs ne doivent pas la contaminer, ou lorsqu’un enrobage capture les deux flux séparément. Dans une session au premier plan dans un terminal, les deux flux arrivent devant vous. Dans ce cas, la distinction change rarement ce que vous faites.

Conservez-le si le script environnant dépend de la séparation. Le retirer parce que le nom semble alarmant change l’endroit où apparaissent les messages et ne corrige rien d’autre.

Ce qu’il ne faut pas changer

Ne traitez pas l’option comme une étape de réparation. La supprimer ne peut pas corriger un certificat, une route ou un échec d’authentification.

Si l’appel contient --config stdin, la configuration est fournie via l’entrée standard. C’est une décision distincte sur la manière dont le fichier est fourni. Changez une chose à la fois et relisez le message réel avant de changer la seconde.