web-dev-qa-db-fra.com

Qu'est-ce que XDG_RUNTIME_DIR?

Pendant que j'essayais d'ouvrir Evince depuis la ligne de commande, cela me donnait une erreur

neo@Muhammad:~$ Sudo evince

No protocol specified

** (evince:4164): WARNING **: Could not open X display
No protocol specified
error: XDG_RUNTIME_DIR not set in the environment.
Cannot parse arguments: Cannot open display:

Comment résoudre ce problème?

12
Muhammad Iliyas

Tout d'abord: XDG_RUNTIME_DIR

Pour répondre à votre première question, "Qu'est-ce que XDG_RUNTIME_DIR?" , il s'agit d'une variable d'environnement définie automatiquement lorsque vous vous connectez. Elle indique à tout programme que vous exécutez où trouver un utilisateur -spécifique répertoire dans lequel il peut stocker de petits fichiers temporaires. Notez que XDG_RUNTIME_DIR est défini par pam_systemd (8) , de sorte qu'il n'est pas réellement lié à X (programmes exécutés graphiquement), qui est le problème que vous semblez rencontrer.

Comment dépanner

Votre deuxième question, "Comment résoudre ce problème?" est très bonne. Cela signifie que vous êtes intéressé non seulement par ce que le correctif est , mais aussi comment pour le résoudre vous-même. Pour commencer, regardez les premiers messages d'erreur en premier. En particulier, la recherche de No protocol specified ou WARNING **: Could not open X display devrait vous montrer que le problème est lié à X (également appelé le système de fenêtrage X ) qui est la façon dont les programmes graphiques sont affichés sur votre écran. Sachant cela devrait soulever de nombreuses questions de dépannage dans votre esprit.

X AFFICHAGE

Votre prochaine question pourrait être, qu'est-ce que c'est "X display" que evince ne peut pas s'ouvrir? Un "affichage" est l'adresse de votre écran.[*] Tout programme qui veut écrire sur votre écran doit connaître l'adresse. Vous pouvez voir ce que votre affichage X est en vérifiant la variable d'environnement DISPLAY:

echo $DISPLAY

Et vous pouvez vérifier ce que Sudo pense de votre AFFICHAGE en tapant:

Sudo -s
echo $DISPLAY
exit

Si cela ne montre rien, alors c'est le problème. (Voir le correctif ci-dessous).

XAUTHORITÉ

Mais que se passe-t-il si ce n'est pas le problème et que DISPLAY est défini correctement dans Sudo? Alors vous pourriez vous demander, est-ce que X a une sorte de permission qui empêche les autres utilisateurs d'écrire sur mon écran? Si vous pensiez cela, vous auriez raison, X a deux méthodes d'autorisation principales: xauth et xhost. Le plus couramment utilisé aujourd'hui est xauth (1) qui utilise la variable d'environnement XAUTHORITY. Encore une fois, vérifions s'il est correctement défini dans Sudo:

echo $XAUTHORITY
Sudo -s
echo $XAUTHORITY
exit

Si XAUTHORITY pointe vers un fichier de votre répertoire personnel, mais qu'il est vide lorsque vous exécutez Sudo, c'est le problème qui se pose.

CORRECTIF: enregistrer les variables d'environnement

Alors, quelle est la solution? Si les variables d'environnement DISPLAY ou XAUTHORITY ne sont pas enregistrées dans Sudo, vous pouvez indiquer Sudo (8) afin de préserver l'environnement à l'aide de l'option -E, comme suit:

Sudo -E evince

Une meilleure façon: env_keep

Vous pourriez bien demander, attendez, si -E fonctionne comme par magie, alors pourquoi n’est-ce pas la valeur par défaut pour Sudo? La réponse est qu'il s'agit d'un risque potentiel pour la sécurité. Les variables d'environnement affectent le fonctionnement des programmes et vous ne souhaitez pas qu'ils soient tous exportés d'un compte utilisateur vers la racine. La méthode "correcte" consiste à ajouter la ligne Defaults env_keep += "DISPLAY XAUTHORITY" au fichier sudoers (5) à l'aide de visudo (8) . Vous pouvez vérifier quelles variables d'environnement sont préservées par Sudo en exécutant:

Sudo sudo -V

(Oui, vous tapez Sudo deux fois). Je recommande de ne pas placer la ligne dans le fichier sudoers par défaut (/etc/sudoers), mais dans un fichier local qui ne sera pas écrasé lors de la mise à niveau de votre système. Vous pouvez faire ça comme ça:

Sudo visudo -f /etc/sudoers.d/local 

Mais attendez, et si rien de ce qui précède ne fonctionne?

Je pense que c'est une réponse assez complète, mais si vous avez toujours des problèmes, il y a une autre chose que je suggérerais. Vous pouvez utiliser xhost (1) pour accorder l’accès à un utilisateur spécifique sur l’hôte local (votre ordinateur), comme suit:

xhost si:localuser:root

Dans ce cas, nous spécifions root comme nom d'utilisateur, puisqu'il s'agit du compte sous lequel Sudo exécute des programmes.


[*]: Q: Je n'ai qu'un seul écran, alors pourquoi un affichage en X nécessite-t-il une "adresse"? A: C'est parce que X peut travaillez non seulement sur votre machine, mais également sur Internet. Avec X, il est facile d'exécuter des programmes sur votre ordinateur qui s'affichent sur d'autres hôtes Internet. et des programmes sur d'autres hôtes qui apparaissent sur votre écran (en supposant que vous leur en donniez la permission).

20
hackerb9

XDG_RUNTIME_DIR est une variable d'environnement définie dans votre contexte X Windows, afin que les programmes puissent rechercher des éléments. Vous (neoname__) avez configuré le contexte graphique.

En essayant d'exécuter evinceen tant que rootname__, vous avez entré la condition dans laquelle un utilisateur (rootname__) tente d'accéder à un autre utilisateur (neoname__). Ceci est considéré comme une mauvaise chose.

Si vous décidez que vous DEVEZ exécuter un éditeur graphique sous le nom rootname__, lisez man gksudo et utilisez gksudoname__.

3
waltinator