Je rencontre un probleme avec kde.
Certains utilisateurs (tres peu en fait) dont les
homes sont montes via nfs, ne peuvent pas se connecter
via kde.
Par contre lorsque l on efface les fichiers caches
contenus dans leur home (notamment ceux lies a x ou
kde j imagine), tout rentre dans l ordre.
Meme si ma question n est pas tres precise (pas de
log) et basee sur des suppositions, se peut il que
cela soit du a des fichiers generes par kde a l
ouverture de session et pas effaces lors de la
fermeture de sesssion suite a un probleme ?(arret
brutal via on/off par exemple)
gnome presente t il le meme comportement
Merci de votre reponse
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Guy Roussin
Bonjour,
Cela serait-il lié au problème que j'évoquais hier (je suis aussi en nfs mais sous gnome et c'est seulement certaines applications qui me posent problème) dans un mail intitulé "xine, totem: can't create mcop directory" ?
Essayer de faire dans une console (ctrl-alt-f1) pour un {user} qui a ce problème :
$ su - {user} $ mkdir /tmp/ksocket-{user} $ mkdir /tmp/kde-{user}
Après ça, essayez de logguer le {user} en question sous kde ...
Vérifiez aussi les droits de /tmp : ils doivent être drwxrwxrwt
La différence (par rapport à un home local) avec le montage des home dir en nfs c'est que root n'a pas le droit d'écrire dedans ...
Guy
Stephane Durieux wrote:
Bonjour
Je rencontre un probleme avec kde. Certains utilisateurs (tres peu en fait) dont les homes sont montes via nfs, ne peuvent pas se connecter via kde.
Par contre lorsque l on efface les fichiers caches contenus dans leur home (notamment ceux lies a x ou kde j imagine), tout rentre dans l ordre.
Meme si ma question n est pas tres precise (pas de log) et basee sur des suppositions, se peut il que cela soit du a des fichiers generes par kde a l ouverture de session et pas effaces lors de la fermeture de sesssion suite a un probleme ?(arret brutal via on/off par exemple)
gnome presente t il le meme comportement
Merci de votre reponse
Bonjour,
Cela serait-il lié au problème que j'évoquais hier (je suis
aussi en nfs mais sous gnome et c'est seulement certaines
applications qui me posent problème) dans un mail intitulé
"xine, totem: can't create mcop directory" ?
Essayer de faire dans une console (ctrl-alt-f1) pour un
{user} qui a ce problème :
$ su - {user}
$ mkdir /tmp/ksocket-{user}
$ mkdir /tmp/kde-{user}
Après ça, essayez de logguer le {user} en question sous kde ...
Vérifiez aussi les droits de /tmp : ils doivent être drwxrwxrwt
La différence (par rapport à un home local) avec le montage
des home dir en nfs c'est que root n'a pas le droit d'écrire
dedans ...
Guy
Stephane Durieux wrote:
Bonjour
Je rencontre un probleme avec kde.
Certains utilisateurs (tres peu en fait) dont les
homes sont montes via nfs, ne peuvent pas se connecter
via kde.
Par contre lorsque l on efface les fichiers caches
contenus dans leur home (notamment ceux lies a x ou
kde j imagine), tout rentre dans l ordre.
Meme si ma question n est pas tres precise (pas de
log) et basee sur des suppositions, se peut il que
cela soit du a des fichiers generes par kde a l
ouverture de session et pas effaces lors de la
fermeture de sesssion suite a un probleme ?(arret
brutal via on/off par exemple)
Cela serait-il lié au problème que j'évoquais hier (je suis aussi en nfs mais sous gnome et c'est seulement certaines applications qui me posent problème) dans un mail intitulé "xine, totem: can't create mcop directory" ?
Essayer de faire dans une console (ctrl-alt-f1) pour un {user} qui a ce problème :
$ su - {user} $ mkdir /tmp/ksocket-{user} $ mkdir /tmp/kde-{user}
Après ça, essayez de logguer le {user} en question sous kde ...
Vérifiez aussi les droits de /tmp : ils doivent être drwxrwxrwt
La différence (par rapport à un home local) avec le montage des home dir en nfs c'est que root n'a pas le droit d'écrire dedans ...
Guy
Stephane Durieux wrote:
Bonjour
Je rencontre un probleme avec kde. Certains utilisateurs (tres peu en fait) dont les homes sont montes via nfs, ne peuvent pas se connecter via kde.
Par contre lorsque l on efface les fichiers caches contenus dans leur home (notamment ceux lies a x ou kde j imagine), tout rentre dans l ordre.
Meme si ma question n est pas tres precise (pas de log) et basee sur des suppositions, se peut il que cela soit du a des fichiers generes par kde a l ouverture de session et pas effaces lors de la fermeture de sesssion suite a un probleme ?(arret brutal via on/off par exemple)
gnome presente t il le meme comportement
Merci de votre reponse
Davy Gigan
This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages.
Le jeudi 15 mars 2007 12:57, Stephane Durieux a écrit :
Par contre lorsque l on efface les fichiers caches contenus dans leur home (notamment ceux lies a x ou kde j imagine), tout rentre dans l ordre.
C'est peut-être parce que dans le ~/.kde, il y a des liens vers des socke ts dans un répertoire /tmp/ksocket-$USER (les sockets étant liées à de s processus locaux de la machine, quand on change de machine, si liens vers l es sockets sont là, les processus et les vraies socket ne sont plus là).
Si tu n'as que des utilisateur malpropres et que c'est bien là le souci, tu peux ajouter un petit script shell à la connexion qui efface les liens contenus dans le ~/.kde de tes utilisateurs. Ajoute un script dans /etc/X11/Xsession.d qui fait /bin/rm $HOME/.kde/socket-* par exemple . ..
Sinon, des questions à se poser pour comprendre :
- Ton souci apparaît-il lorsqu'un utilisateur se déconnecte propremen t puis se reconnecte sur un autre client du réseau ? - Quid d'une déconnexion/connexion malpropre sur le même poste (via u n Ctrl-Alt-Backspace par exemple) ?
Un autre souci réccurent avec les clients nfs : les problèmes de lock d e fichier. Tu dois t'assurer d'avoir le package nfs-common et le programme rpc.stad de démarré sur tous les clients nfs ... En cas de souci, les applications nécessitant un lock et ne l'obtenant pas freezent.
Tu peux consulter le ~/.xsession-errors des utilisateurs qui n'arrivent pas à se connecter à la recherche d'une éventuelle information. S'il n'y a ri en, tu sors l'artillerie lourde : strace. tu peux placer la commande « strace -f » avant le lancement de ta session avec un « 2>/chemin/fichier » derriè re ... Mais attention ça va faire beaucoup d'informations dans le fichier en question :)
-- Davy Gigan System & Network Administration [Please no HTML, I'm not a browser] University Of Caen (France) [Pas d'HTML, je ne suis pas un navigateur]
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
Le jeudi 15 mars 2007 12:57, Stephane Durieux a écrit :
Par contre lorsque l on efface les fichiers caches
contenus dans leur home (notamment ceux lies a x ou
kde j imagine), tout rentre dans l ordre.
C'est peut-être parce que dans le ~/.kde, il y a des liens vers des socke ts
dans un répertoire /tmp/ksocket-$USER (les sockets étant liées à de s
processus locaux de la machine, quand on change de machine, si liens vers l es
sockets sont là, les processus et les vraies socket ne sont plus là).
Si tu n'as que des utilisateur malpropres et que c'est bien là le souci, tu
peux ajouter un petit script shell à la connexion qui efface les liens
contenus dans le ~/.kde de tes utilisateurs. Ajoute un script
dans /etc/X11/Xsession.d qui fait /bin/rm $HOME/.kde/socket-* par exemple . ..
Sinon, des questions à se poser pour comprendre :
- Ton souci apparaît-il lorsqu'un utilisateur se déconnecte propremen t puis se
reconnecte sur un autre client du réseau ?
- Quid d'une déconnexion/connexion malpropre sur le même poste (via u n
Ctrl-Alt-Backspace par exemple) ?
Un autre souci réccurent avec les clients nfs : les problèmes de lock d e
fichier. Tu dois t'assurer d'avoir le package nfs-common et le programme
rpc.stad de démarré sur tous les clients nfs ... En cas de souci, les
applications nécessitant un lock et ne l'obtenant pas freezent.
Tu peux consulter le ~/.xsession-errors des utilisateurs qui n'arrivent pas à
se connecter à la recherche d'une éventuelle information. S'il n'y a ri en, tu
sors l'artillerie lourde : strace. tu peux placer la commande « strace -f »
avant le lancement de ta session avec un « 2>/chemin/fichier » derriè re ...
Mais attention ça va faire beaucoup d'informations dans le fichier en
question :)
--
Davy Gigan
System & Network Administration [Please no HTML, I'm not a browser]
University Of Caen (France) [Pas d'HTML, je ne suis pas un navigateur]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le jeudi 15 mars 2007 12:57, Stephane Durieux a écrit :
Par contre lorsque l on efface les fichiers caches contenus dans leur home (notamment ceux lies a x ou kde j imagine), tout rentre dans l ordre.
C'est peut-être parce que dans le ~/.kde, il y a des liens vers des socke ts dans un répertoire /tmp/ksocket-$USER (les sockets étant liées à de s processus locaux de la machine, quand on change de machine, si liens vers l es sockets sont là, les processus et les vraies socket ne sont plus là).
Si tu n'as que des utilisateur malpropres et que c'est bien là le souci, tu peux ajouter un petit script shell à la connexion qui efface les liens contenus dans le ~/.kde de tes utilisateurs. Ajoute un script dans /etc/X11/Xsession.d qui fait /bin/rm $HOME/.kde/socket-* par exemple . ..
Sinon, des questions à se poser pour comprendre :
- Ton souci apparaît-il lorsqu'un utilisateur se déconnecte propremen t puis se reconnecte sur un autre client du réseau ? - Quid d'une déconnexion/connexion malpropre sur le même poste (via u n Ctrl-Alt-Backspace par exemple) ?
Un autre souci réccurent avec les clients nfs : les problèmes de lock d e fichier. Tu dois t'assurer d'avoir le package nfs-common et le programme rpc.stad de démarré sur tous les clients nfs ... En cas de souci, les applications nécessitant un lock et ne l'obtenant pas freezent.
Tu peux consulter le ~/.xsession-errors des utilisateurs qui n'arrivent pas à se connecter à la recherche d'une éventuelle information. S'il n'y a ri en, tu sors l'artillerie lourde : strace. tu peux placer la commande « strace -f » avant le lancement de ta session avec un « 2>/chemin/fichier » derriè re ... Mais attention ça va faire beaucoup d'informations dans le fichier en question :)
-- Davy Gigan System & Network Administration [Please no HTML, I'm not a browser] University Of Caen (France) [Pas d'HTML, je ne suis pas un navigateur]
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
