Gedit ne se lance plus en console administrateur

Support Debian
#1

En interface graphique (gnome-shell), de tout temps j’ai utilisé gedit en console administrateur pour modifier des fichiers système.
(il y a bien nano mais qui n’est pas en interface graphique et moins pratique, que je n’utilise que si je ne suis pas en graphique).

Or depuis quelque temps, sur ma Sid, gedit refuse de se lancer :

[code]root@990FX6100:/home/andre# gedit
No protocol specified

** (gedit:3926): WARNING **: Could not open X display
No protocol specified
Impossible d’ouvrir l’affichage :
Lancez « gedit --help » pour voir la liste complète des options en ligne de commande disponibles.
root@990FX6100:/home/andre# [/code]

Il ne semble donc pas pouvoir lancer d’affichage X en root.

Si j’utilise le help conseillé :

[code]root@990FX6100:/home/andre# gedit --help
Utilisation :
gedit [OPTION…] [FICHIER…] [+LIGNE[:COLONNE]] - Édite des fichiers texte

Options de l’aide :
-h, --help Affiche les options de l’aide
–help-all Affiche toutes les options de l’aide
–help-gtk Affiche les options GTK+
–help-sm-client Show session management options

Options de l’application :
-V, --version Affiche la version de l’application
–list-encodings Affiche la liste des valeurs possibles pour l’option de codage
–encoding=CODAGE Définit le codage de caractères à utiliser pour ouvrir les fichiers listés dans la ligne de commande
–new-window Crée une nouvelle fenêtre de premier niveau dans une instance existante de gedit
–new-document Crée un nouveau document en utilisant une instance existante de gedit
-g, --geometry=GÉOMÉTRIE Définit la taille et la position de la fenêtre (LARGEURxHAUTEUR+X+Y)
-w, --wait Ouvre les fichiers et bloque le processus jusqu’à la fermeture des fichiers
-b, --background Exécute gedit en arrière-plan
-s, --standalone Exécute gedit en mode autonome
–display=AFFICHAGE Affichage X à utiliser

root@990FX6100:/home/andre# [/code]

je ne sais pas très bien quoi mettre à la place de AFFICHAGE
(j’ai essayé X11 et quelques autres arguments sans résultat)

Gedit n’est pas le seul concerné, même chose pour leafpad :

root@990FX6100:/home/andre# leafpad No protocol specified leafpad: Impossible d'ouvrir l'affichage : root@990FX6100:/home/andre#

mais là c’est plus succinct comme message d’erreur !

Je précise que j’ai une autre config similaire en amd64 et carte graphique nvidia (bien que plus ancienne) en testing, et que ça continue de marcher sans problème.
Le problème est le même en kernel 3.8.2 et 3.9.1 .

A votre avis, pourquoi gedit ne se lance plus et que puis-je essayer comme argument à la place de “AFFICHAGE” ?

#2

Salut,

T’as essayé avec gksu/gksudo? J’avais le même genre de problème et c’est le lancement des applis en root par gk* qui m’a permis de régler ça.

#3

grilled !!

Ca répond à ma question :

[quote=“bobo38”]J’avais oublié ces histoires de gksu (ça me rappelle des souvenirs) :
– Y a-t-il vraiment des cas où tu ne peux pas lancer une appli graphique à partir d’un terminal root ?
– gksu n’est pas juste un truc pour faire des « lanceurs » permettant de lancer des applications avec droits root d’un clic sur une icônes ?
– (mon dieu, j’ai presque oublié le vocabulaire de l’interface graphique, c’est grave docteur ?!)[/quote]

https://www.debian-fr.org/pause-cafe-lambda-extenue-au-risque-de-passer-pour-un-debile-t43771-25.html

Il existerait bel et bien des cas où les applis graphiques ,ne peuvent pas être lancées depuis un terminal root. Dans ce cas il conviendrait d’utiliser gksu comme tu utiliserais sudo…

[quote=“etxeberrizahar”]Pourquoi gksu ?
g comme graphique, su comme substitute user//super user.
Parce que tous les systèmes ne permettent pas à root de lancer des applications graphiques au débotté, ça dépend des réglages qui ont cours chez les uns et les autres.[/quote]

#4

Salut,

Il va falloir vous faire à l’idée que vous n’êtes plus sous Ubuntu. Ce n’est pas depuis quelques temps, c’est de tout temps que çà à été comme çà sous Debian :slightly_smiling:

#5

Faux ! Je peux lancer gedit depuis un émulateur de terminal avec des droits administrateurs sans problème. Je l’ai testé avec succès avant de le conseiller.

Ma config : Wheezy + XFCE + je serais incapable de donner le nom de l’émulateur de terminal (en tout cas celui de base de l’installeur DebianXFCE)

taureau89_9, je comprends que ça puisse surprendre : ce que je ferais en premier, tester un autre émulateur de terminal pour essayer d’isoler le problème. Suggestion : terminator.

#6

Idem ici, j’ai toujours pu lancer geany en root sans gksu depuis ma dernière install de debian, j’utilise seulement gksu par habitude. Je viens de tester, aucun problème avec urxvt ni xterm (mais je doute que l’émulateur de terminal ait une quelconque influence).

#7

Rah ! Prochain facteur à tester : l’environnement de bureau. Est-ce lié à l’environnement de bureau ou à des choses biens plus profondes dans le système ?

  • Gaawr, utilises-tu aussi Gnome-shell comme taureau_89 ?
  • Est-ce que l’un d’entre vous a un gestionnaire de bureau alternatif ?

Autre facteur à tester :
Que se passe-t-il en passant par sudo depuis un terminal utilisateur ? Est-ce que le problème persiste ? (je sais sudo n’est pas prévu pour cela)

#8

bobo38 > non aucun DE, je tourne sous Subtle WM. Pas de DE alternatif, j’ai rien d’autre installé.

M’enfin c’est pas bien méchant, un petit gksu devant et ça règle le problème si jamais il survient.

#9

Totalement faux.
Comme je l’ai dit dans mon message, sur mon autre config testing ça continue de marcher, comme ça a toujours marché.
Et sur ma Sid il n’y a que depuis peu de temps que ça ne fonctionne plus.

Tu ferais mieux de nous dire ce qui a changé, ce serait de ta part plus constructif que ton type de remarque habituel.

#10

[quote=“taureau89_9”]A votre avis, pourquoi gedit ne se lance plus[/quote]Par sécurité.
Si tu veux le lancer quand même en root avec gnome-shell, tu ouvres gnome-terminal en simple utilisateur et tu entresgksu geditA ce moment là va apparaître une fenêtre où tu seras invité à rentrer ton MDP root.

#11

Tout simplement parce depuis toujours je suis tellement habitué à la méthode console administrateur/gedit que je n’en connaissais même pas d’autre.

Mais j’ai essayé, merci.

Par contre ça ne règle toujours pas le problème, pourquoi ce qui a toujours marché, d’un coup, ne marche plus.

[EDIT] merci talogue, j’avais fait l’essai entre temps.[/EDIT]

#12

Il est vrai que le comportement de gnome a récemment changé et qu’il était avant possible de lancer beaucoup d’applications graphiques depuis gnome-terminal en root.

Depuis quelques temps ça évolue, pour gedit par exemple. Mais je viens de tester nautilus et je peux toujours le lancer à partir de gnome-terminal en root en entrant simplement nautilus.

#13

Comme ça marche avec gksu, je passe le sujet en résolu, bien que je soie curieux et que j’aimerais bien savoir pourquoi ce qui chez moi a toujours marché d’un coup ne fonctionne plus.

Toutefois, j’ai un autre souci, récent lui aussi, avec la console administrateur.
Et je me demande si ce n’est pas lié.

Aussi j’ouvre un autre sujet pour le traiter.

#14

Salut,

[quote=“taureau89_9”]Comme ça marche avec gksu, je passe le sujet en résolu, bien que je soie curieux et que j’aimerais bien savoir pourquoi ce qui chez moi a toujours marché d’un coup ne fonctionne plus.
[/quote]

As tu visionné les changelogs ?

/usr/share/doc/le_paquet_concerné/changelog.gz /usr/share/doc/le_paquet_concerné/changelog.Debian.gz

[quote=“aptitude show apt-listchanges”]Description : Outil de notification de changement d’historique d’un paquet
L’outil apt-listchanges peut comparer une nouvelle version d’un paquet avec celle actuellement installée et montrer ce qui a été modifié en affichant les entrées pertinentes des
fichiers changelog et NEWS de Debian.

Il peut être exécuté sur plusieurs fichiers archives .deb à la fois pour obtenir une liste de tous les changements causés par l’installation ou la mise à jour d’un ensemble de
paquets. S’il est configuré comme un greffon à APT, il effectuera ceci automatiquement pendant les mises à jour.[/quote]

#15

Curieux chez moi ça fonctionne.

Ca vient peut être du terminal (j’ai gnome-terminal 3.4 et non 3.8 ) et pas de gedit.

#16

Oui car je suis en 3.8 .

S’il le faut je downgraderai mais pas vraiment nécessaire en utilisant gksu .

#17

J’allais oublié …

Tu noteras qu’il t’est possible (recommandé) d’être systématiquement informé par courriel de tout ou parti des modifications à venir.


#18

Salut,

Mes excuses, je ne suis pas sous Gnome !

[quote]
root@ssd:/home/gerard# kate
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
kate(32501)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
KCrash: Application ‘kate’ crashing…
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/root/.kde/socket-ssd/kdeinit4__0
Warning: connect() failed: : Aucun fichier ou dossier de ce type
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi directly
drkonqi(32502)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
root@ssd:/home/gerard# exit[/quote]
Et j’ai tendance à oublier que KDE c’est mal :slightly_smiling:

#19

Les adorateurs du mal, le vrai, n’utilisent pas gnome ou kde.

Evil linux

Pas de jaloux, les kdeistes ont l’équivalent de ce qu’ont les gnomeux.
Gksu pour gnome, Kdesu pour kde ( il existe également kdesudo).

Le manuel de kdesu est quelque peu sec pour expliquer l’interaction avec X.
L’aide de kdesu consultable au moyen de konqueror/dolphin ou khelpcenter nous en dit davantage.

help:/kdesu/Internals.html#x-authentication

[quote]
X authentication
The program you execute will run under the root user id and will generally have no authority to access your X display. KDE su gets around this by adding an authentication cookie for your display to a temporary .Xauthority file. After the command exits, this file is removed.
If you don’t use X cookies, you are on your own. KDE su will detect this and will not add a cookie but you will have to make sure that root is allowed to access to your display. [/quote]
Kdesu ajoute une autorisation temporaire d’accès à X au moyen d’un cookie Xauthority. Après que la commande se finit, le cookie est supprimé.

Hors de ce cadre
(“make sure that root is allowed to access to your display”), lorsque xhost n’y peut rien et que s’escrimer avec Xauthority vous assomme, on peut contourner avec ssh -X sur le système local.

$ ssh -X 127.0.0.1

#20

Merci :slightly_smiling: