WSL Ubuntu : Impossible de lancer Terminator

J'avais initialement voté pour fermer ce sujet comme un duplicata du sujet général. Comment exécuter des applications GUI avec le sous-système Windows pour Linux ? question, mais la réalité est que c'est un peu différent.

Nous n'avons pas vraiment d'objectif général, "Comment puis-je déterminer le bon DISPLAY variable pour la WSL ?" Question Puisque nous avons fini par résoudre ce problème dans les commentaires, permettez-moi de passer en revue les différentes options dans une réponse.

Tout d'abord, quelques "termes de recherche". Vous pouvez rencontrer différentes erreurs lorsque vous essayez d'exécuter des applications GUI Linux dans WSL :

• Error: Unable to open display
• Error E233: cannot open display
• Error: (SDL_Init) No available video device (à partir des applications SDL)
• Error: An OpenGL context could not be created

D'abord, lisez Comment exécuter des applications GUI avec le sous-système Windows pour Linux ? . Vous devrez choisir l'une de ces solutions afin d'exécuter des applications GUI Linux dans WSL.

Mais si vous rencontrez toujours des problèmes, vous devrez peut-être prendre des mesures supplémentaires.

WSL2 : Windows 11 avec WSLg

Si vous utilisez Windows 11 avec WSLg (l'option WSL par défaut pour l'exécution d'applications GUI Linux dans Windows 11), alors vos DISPLAY devrait être définie par WSL pour vous. Elle doit être :

$ echo $DISPLAY
:0

C'est l'équivalent de DISPLAY=localhost:0 car WSLg fonctionne à l'intérieur de la VM WSL2, il est donc "local" à votre session WSL.

Les règles du pare-feu devraient également être définies automatiquement pour vous.

Et vous auriez dû :

$ echo $WAYLAND_DISPLAY
wayland-0

Pour exécuter les applications Wayland (le successeur de X).

Si ces variables ne sont pas définies correctement :

• Vérifiez vos fichiers de configuration de démarrage pour voir si vous (ou une application que vous avez installée) configurez le paramètre DISPLAY à quelque chose d'autre là-bas.

  Essayez de lancer WSL (à partir de PowerShell) sans exécuter votre démarrage Bash avec :

  wsl ~ -e bash --noprofile --norc

  Et ensuite, vérifiez à nouveau les variables. Si elles sont correctes maintenant, alors quelque chose dans votre startup est de les changer. Vous devrez modifier votre configuration de démarrage, trouver le coupable et le corriger.

• Exécutez-vous un script d'activation Systemd script ? Si oui, essayez sans lui. Par défaut, l'environnement Systemd ne dispose pas de l'option DISPLAY (et d'autres variables WSL intégrées). La plupart des scripts de Systemd-enablement tenteront de gérer cela, mais ils peuvent avoir rencontré un cas de figure auquel ils ne s'attendaient pas.

WSL1 : Windows 10 ou 11 avec un serveur X tiers

Lors de l'utilisation d'un serveur X tiers comme VcXsrv (comme dans la question originale ici) dans WSL1, la fonction DISPLAY devrait à nouveau être :0 comme avec WSLg ci-dessus.

$ echo $DISPLAY
:0

Courses WSL1 dans le même réseau comme l'hôte Windows, donc VcXsrv (etc.) sera local à WSL1.

Aucune règle spéciale de pare-feu n'est requise lors de l'exécution de WSL1 avec un serveur Windows X tiers.

WSL2 : Windows 10 ou 11 avec un serveur X tiers

C'est le cas le plus compliqué, et celui qui fait l'objet de la question initiale. Vous avez besoin d'au moins deux choses en place pour communiquer avec VcXsrv (etc.) sous WSL2 :

• L'adresse IP correcte pour le DISPLAY variable.
• Règles de pare-feu pour autoriser l'accès

Ces deux éléments sont nécessaires car WSL2 fonctionne dans un environnement réseau séparé que l'hôte Windows. Il fonctionne à l'aide d'une interface réseau virtuelle derrière un commutateur virtuel qui est NATé. Par conséquent, localhost:0 (ou simplement :0 ) fait référence à la WSL2 interface réseau, no l'hôte Windows.

Dans une configuration WSL2 par défaut, le résolveur DNS est réglé (par WSL) sur l'hôte Windows, en utilisant l'adresse IP de ce commutateur virtuel. Par conséquent, vous pouvez essayer plusieurs options pour déterminer l'IP correcte pour le commutateur virtuel. DISPLAY :

• export DISPLAY="$(hostname).local:0"

  Elle utilise mDNS, qui est disponible dans WSL2 depuis quelques années. Voir cette réponse sur Stack Overflow pour plus d'informations. Cela nécessite l'utilisation du résolveur par défaut.

• export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0

  Cela analyse le /etc/resolv.conf pour obtenir l'adresse IP de l'hôte Windows où le résolveur est exécuté. Là encore, il faut que le résolveur WSL2 par défaut soit utilisé.

• export DISPLAY=$(host nom d'hôte --long | grep -oP '(\s)\d+(\.\d+){3}' | tail -1 | awk '{ print $NF }' | tr -d '\r')

  Si les deux options ci-dessus ne fonctionnent pas, alors (crédit cette réponse à Ask Ubuntu cette option tentera d'obtenir l'adresse IP Windows de l'ordinateur. primaire interface réseau. Il s'agit généralement d'une adresse de réseau privé telle que 192.168.1.100 ou 10.0.1.5 .

  Si cette adresse est statique, vous pouvez simplement la coder en dur, ce qui a fonctionné pour le PO :

  export DISPLAY=192.168.1.100:0` # Adjust with your actual IP

  S'il est attribué dynamiquement et change fréquemment, vous pouvez utiliser la commande ci-dessus pour tenter de l'obtenir. Cependant, notez que c'est beaucoup plus lent que toute autre méthode. Sur mon système relativement rapide, le processus prend environ 3 secondes.

Règles de pare-feu

Lorsque vous utilisez WSL2 avec un serveur X tiers, vous devez également vous assurer que le pare-feu autorise l'accès de WSL2 à l'hôte Windows.

La première fois que vous tentez de vous connecter au serveur X, Windows Defender sollte affiche une boîte de dialogue dans laquelle vous pouvez autoriser l'accès à partir de réseaux publics et/ou privés. Malheureusement, le réseau WSL2 est considéré comme "public" depuis l'hôte Windows, et vous devez donc vous assurer que Public est sélectionné.

Note : D'après mon expérience, le dialogue est souvent évoqué derrière d'autres fenêtres, et peuvent être facilement manquées. Si cela se produit, et que cette boîte de dialogue est fermée sans autoriser le trafic, une règle de "refus" sera probablement mise en place.

Toutefois, une règle publique "Allow" signifie également que le pare-feu autorise le trafic sur ce port sur d'autres réseaux publics (comme les réseaux wifi publics). Cela peut constituer un risque pour la sécurité, si vous exécutez le serveur X en dehors de votre réseau domestique.

Tout d'abord, assurez-vous que les règles sont en place pour permettre l'accès, au moins. Depuis une session administrative PowerShell :

Get-NetFirewallApplicationFilter |? { $_.Program -like "*vcxsrv*" } | Get-NetFirewallRule

Ajustez le -like pour l'exécutable de votre serveur X.

Le plus simple, à ce stade, est de chercher le fichier DisplayName dans la sortie. Ensuite, exécutez Pare-feu Windows Defender à partir du menu Démarrer et trouver les règles d'association dans Règles d'entrée . Assurez-vous que des règles "d'autorisation" sont en place pour les réseaux publics (au moins).

Cette réponse est devenue un peu longue, et ajouter des informations sur la limitation de la règle de pare-feu au trafic provenant de WSL2 (par opposition à d'autres réseaux publics) est probablement un peu hors de propos. Si quelqu'un est intéressé par la façon de procéder, veuillez poster une question distincte sur ce sujet particulier.