Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

"Se connecter à un serveur" bouffe 100% CPU (Lucid)

malbo

Edit le 2 avril 2010 : le problème de CPU à 100% est résolu chez moi avec la mise à jour du paquet libgnome-keyring - 2.30.0-0ubuntu3
Voir les détails dans le post #17 ci-dessous

Avec Lucid installé dans mon PC Medion (ma signature), j'ai le bug 532024 qui est décrit là :
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/532024

Edit : on parle aussi de ce problème - bug 611584 - dans ce lien :
https://bugzilla.gnome.org/show_bug.cgi?id=611584
Ainsi que dans ce lien sur le bug 530605 :
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/530605
Et les pov gens qui veulent se connecter à un serveur ftp en bavent aussi :
https://bugs.launchpad.net/ubuntu/lucid/+source/gvfs/+bug/538764

Mais au démarrage de mon PC, il arrive que ça fonctionne pour arriver à voir les partages sur le PC Windows distant en faisant :

Raccourcis > se connecter à un serveur 
puis je remplis les champs :
type de service : partage Windows 
Serveur : 192.168.0.1 # c'est l'adresse IP de mon PC distant

Arrivé là (je peux voir mes dossiers partagés sur le PC distant), il ne faut surtout pas que je veuille parcourir ces partages dans le navigateur de fichiers parce que ça merde avec CPU à 100%. C'est le processus gvfsd-smb-browse qui bouffe le CPU (mais dans certains cas, ça peut aussi être le processus gvfsd-smb qui bouffe du CPU). Donc si par chance j'arrive à voir les partages dans mon PC distant comme je viens de le dire, il faut que j'ouvre un par un les dossiers partagés comme suit :

Raccourcis > se connecter à un serveur 
puis je remplis les champs :
type de service : partage Windows 
Serveur : 192.168.0.1 
Partage : partage1 # le nom de mon premier dossier partagé sur le PC distant

Idem pour le deuxième dossier partagé :

Raccourcis > se connecter à un serveur 
puis je remplis les champs :
type de service : partage Windows 
Serveur : 192.168.0.1 
Partage : partage2 # le nom de mon deuxième dossier partagé sur le PC distant

Et ainsi de suite. Oui, c'est bien merdique...
Quand un dossier partagé est monté de cette façon, j'arrive alors à naviguer dedans sans problème. On dirait que Nautilus à un "barre" à franchir qui est le niveau du dossier partagé et qu'une fois cette barre franchie, on peut naviguer sans problème.

Edit le 17 mars 2010 : Non, n'essayez même pas d'utiliser fstab comme je l'indique dans les lignes suivantes car c'est vraiment une technique pourrie. J'ai pratiqué Autofs plus tard (voir post #16) et c'est déjà mieux que de renseigner le fstab

Comme certaines fois, il m'est impossible aujourd'hui d'utiliser la fonction "se connecter à un serveur", j'ai utilisé le montage automatique en rajoutant mes partages dans le fichier fstab. La procédure est présentée là (il faut installer le paquet smbfs comme c'est mentionné) :
http://doc.ubuntu-fr.org/samba#monter_manuellement_et_automatiquement_un_dossier_partage_dans_le_systeme_de_fichiers
Cela fonctionne. Je donne pour info ce que j'ai mis dans mon fichier fstab :

//192.168.0.1/partage1     /media/partage1     smbfs     _netdev,guest     0     0
//192.168.0.1/partage2     /media/partage2     smbfs     _netdev,guest     0     0

Évidemment, j'ai changé les noms des partages (c'est ma vie quoi...). Il a fallu créer auparavant les dossiers partage1, partage2, etc...dans /media

Edit le 18 mars 2010 : cette soluce de montage automatique est provisoire et elle a un effet collatéral : si j'éteins le PC Windows distant, le PC "Lucid" plante à l'extinction, probablement parce qu'il ne peut pas démonter les partages vu que le PC distant est coupé. Je suis alors obligé d'éteindre le PC "Lucid" avec 3 secondes sur le bouton arrêt du PC. Ce n'est jamais bon...

Maisondouf

chaud, la bidouille !

gestion-tic

Bonjour,
Je communique via ton sujet. (je ferai gaffe de bien lire les sujets la prochaine fois ...). J'ai réalisé ta procédure pour accéder à des données réseau (montées dans le répertoire /home/xxx/yyy). Mon seul souci est que je souhaiterais un accès en lecture/écriture. Apparemment "root" est le seul à pouvoir écrire. Pour écrire, il me faut passer par bouton droit sur le dossier monté puis "ouvrir en tant qu'administrateur" que j'ai installé dans mon menu contextuel Nautilus. Y a-t-il moyen de donner automatiquement des droits d'écriture à un utilisateur non "root" ?

malbo

gestion-tic a écritY a-t-il moyen de donner automatiquement des droits d'écriture à un utilisateur non "root" ?

Moi, je suis faible des genoux avec ces problèmes de droits. Si quelqu'un sait te répondre...
Je ne comprends pas trop pourquoi tu as cherché à faire un montage dans /home au lieu de faire un montage dans /media comme j'ai fait et comme c'est précisé dans le lien que j'ai donné dans mon post #1 :
http://doc.ubuntu-fr.org/samba#monter_manuellement_et_automatiquement_un_dossier_partage_dans_le_systeme_de_fichiers

Maisondouf

Le processus fautif a changé de nom mais il buggue toujours.

Maintenant il s'appelle "gvfsd-smb-brows" et pompe toujours 100% du cpu

Maisondouf

Ah chez moi ça remarche quand je passe par 'se connecter à un serveur' que je choisi 'Partage Windows' et que je rempli seulement le nom du serveur et le nom du partage.

Par contre, en passant par nautilus en cliquant sur 'Reseau', j'ai bien la liste des pc serveurs qui s'ouvre mais si je clique sur un pc, là ça plante.
cpu 100%

gwado

J'avais le même problème mais pour sftp et ftp.
J'ai réinstallé lucid via la beta et depuis ça fonctionne.
À suivre.

malbo

Moi, par rapport à mon post #1, la fonction "se connecter un serveur" ne marche toujours pas bien. Il arrive que ça fonctionne puis ça se met à bloquer avec CPU à 100%. Pour moi, c'est bien enfoncé comme foutu bogue et je ne pense pas qu'il va être résolu de sitôt.

gwado

T'as essayé en réinstallant totalement ?

J'avais réinstaller gvfs mais ça n'avait pas résolu le problème.

malbo

gwado,
Avant de me lancer dans une réinstall à neuf, je vais attendre un peu que la pluie de mises à jour se calme parce que je viens de voir ce matin qu'une mise à jour de gvfs est proposée. Ce paquet gvfs a certainement à voir avec le bogue puisque comme je l'ai signalé dans le post #1, ce sont les processus gvfsd-smb-browse et gvfsd-smb qui font grimper le CPU à 100%.

temps

Bonjour,
Mon retour d'expérience sous lucid et raccourcis---->Réseau
Il est vrai qu'entre la version alpha1 et alpha3 les postes les plus puissants ont rencontrés un problème de connection, mais autrement ils fonctionnent bien. Pour les postes un peu plus anciens +7ans simple coeur "optiplex GX260 Dell", les ordinateurs se trouvant sur le réseau apparaissent bien mais il est vrai que le navigateur de fichiers n'arrivent pas à ouvrir les dossiers partagés sous samba. J'ai pensé à vinacre mais j'utilise pour l'instant la clé USB en solution.
Cordialement

malbo

gwado,
Sur ta suggestion, je me suis fendu d'une réinstallation de Lucid sur mon PC Medion (dans ma signature) avec lequel j'ai le problème. Résultat (après mises à jour bien sûr) : rien de changé, c'est à dire que ça ne merde pas systématiquement quand je parcours le réseau (ou bien que je fais "se connecter à un serveur") mais souvent ça le fait. A ce moment, j'ai les 3 PC dans ma signature sous Lucid qui sont en réseau avec samba et je fais des essais de parcours réseau. Seul le PC Acer (le plus moderne) fonctionne sans problème et ne me fais jamais le Pb, cependant que les autres me font le problème quand je parcours le réseau avec CPU à 100% (pas systématique comme j'ai dit mais j'y arrive souvent)

malbo

Les processus qui font grimper le CPU à 100% sont gvfsd-smb-browse et gvfsd-smb. J'ai utilisé la méthode proposée là :
http://doc.ubuntu-fr.org/rapporter_un_bug#bogues_d_un_programme
C'est à dire :

le plus simple est d'aller sur le site http://packages.ubuntu.com/  où vous pouvez faire une recherche sur le nom du processus (fichier) en filtrant suivant votre version d'Ubuntu

Pour trouver que ces deux processus appartiennent au paquet gvfs-backends, lequel paquet a été mis à jour hier (de la version 1.5.5-0ubuntu1 à 1.5.5-0ubuntu2) donc l'espoir est passé très près que cette mise à jour pouvait peut-être réparer le problème mais chez moi, ça merde toujours pareil. Comme je l'ai dit plus haut, j'ai mes deux vieux PC qui ont le problème et mon PC Acer plus récent qui n'a pas le problème.

temps

Bonjour,
Je pense que le problème dans la 10.4 est lié à deux actions.
La première est que la 10.4 scanne tous les disques dures, en exemple quand on démarre en live sur un P.C. contenant des disques dures pleins de vidéo, juste après son démarrage nous pouvons voir une immense activité du P.C. sans raison. Recherche de fichiers = ressources !
La deuxième provient du fait que la 10.4 a beaucoup de mal avec la gestion des disques. Nous pouvons nous en apercevoir facilement en essayant d'utiliser gparted sous la 10.4 ou encore un samba modifié qui m'a apporté dans mes tests qu'un error file system, et un plantage de serveurs. Ou encore toujours en live 10.4 le déplacement de données ou l'écriture en virtuel d'un nouveau smb.conf était impossible.
J'ajoute ceci d'assez étonnant, sur un P.C. contenant deux disques dures, un pour l'O.S. et un pour les données (principalement des vidéos), quand j'ai testé la beta de 10.4, celle-ci est allée effacer plusieurs de mes vidéos sur le disque dure de données. Ces vidéos de différents formats (vob,mpeg,xvid) avaient été créée par moi et avaient pour origine plusieurs caméras (numériques ou VHS), elles ne contenaient aucune image sortant de l'ordinaire et les montages avaient été fait entièrement sous linux.

malbo

Rien de changé pour moi : ça merde toujours. Pour pouvoir partager, il faut que je renonce à parcourir le réseau, que j'autorise l'accès aux partages sans mot de passe, c'est à dire que pour les PC démarrés sous Ubuntu, je dois cocher la case "Accès d'évaluation (pour les personnes sans compte utilisateur)" comme c'est expliqué dans la partie suivante :
http://doc.ubuntu-fr.org/samba#partager_un_dossier_personnel_usershares
Ce qui constitue un défaut important pour la sécurité dans le réseau
Moyennant cela, je peux monter mes partages dans fstab comme j'ai déjà indiqué en bas de mon post #1
Je ne le sens pas : la résolution du bug n'est pas pour demain et je ne suis pas prêt de surfer sur le réseau avec Lucid. Le montage en barreaux de chaise avec fstab, c'est bien ringard et ça fait chier.

malbo

J'ai remplacé le montage pourri par fstab avec la technique Autofs telle que décrite ici pour "Accès aux partages sans authentification" :
http://doc.ubuntu-fr.org/autofs_avec_samba#acces_aux_partages_sans_authentification
Cette technique est beaucoup plus adaptée à un réseau en Wifi pour plusieurs raisons j'imagine mais dans mon cas, elle est mille fois mieux que le montage par fstab parce que le montage n'est fait que si on a besoin de parcourir le réseau.
J'ai l'impression d'être revenu à Dapper Drake avec ce genre de bidouille imprégnée de ligne de commande que je ne sais même pas ce que ça veut dire. Faut bien préparer l'avenir pas marrant parce que les développeurs ont dû mettre la priorité sur les boutons de fenêtre et c'est pas pour demain qu'ils vont résoudre ce foutu bogue.

malbo

Le problème de CPU à 100% est résolu sur mes deux PC qui avaient le problème ( HP Vectra et Medion : voir ma signature) par la mise à jour suivante du paquet libgnome-keyring0 :
libgnome-keyring0 (2.30.0-0ubuntu1) to 2.30.0-0ubuntu3
C'est présenté officiellement ici (#47 du bug 530605) :
https://bugs.launchpad.net/ubuntu/+source/libgnome-keyring/+bug/530605/comments/47
Il y a encore des problèmes avec cette fonctionnalité : il ne faut cocher aucune des deux cases "se souvenir..." sinon on ne peut ouvrir qu'un seul partage par serveur. Donc, en pratique, il faut juste rentrer son mot de passe s'il est demandé (cas d'un accès avec authorisation) et laisser la choix par défaut déjà coché "oublier immédiatement le mot de passe". Et là, on peut ouvrir tous les partages qu'on veut. Ces problèmes que je rencontre sont également rencontrés par timosha dans le commentaire #52 du bug 530605 :
https://bugs.launchpad.net/ubuntu/+source/libgnome-keyring/+bug/530605/comments/52

Edit le 10 avril 2010 : le dysfonctionnement qui apparaît quand on sélectionne une des deux cases "se souvenir..." est toujours présent sur mon PC Medion (ma signature). Par contre, je n'ai pas ce Pb sur mon PC Acer (avec lequel je n'avais pas non plus le Pb CPU 100%)