[nepomuk] Toujours en train de scanner le même dossier

[nicollivier]

Alors voici un nouveau souci qui apparut après ma ré-install....

J'ai le service strigi/nepomuk qui est en train d'indexer toujours le même dossier à chaque redémarrage....
Le dossier en question est celui pour Texlive, je l'ai installé dans mon home. Ce dossier étant composé d'un certain nombres de fichiers, cela prend pas mal de temps à indexer et surtout pas mal de ressource.

Je ne comprends pas du tout pourquoi il le scanne à chaque fois, surtout que je ne le touche jamais, donc il n'est pas modifié.....

Est-ce quelqu'un aurait une idée ?!

Nico

[benjarobin]

Pourquoi tu ne décoche pas l'indexation de ce dossier. Il a sûrement pas finit donc il continue

[nicollivier]

J'y ai pensé à cela aussi, mais je suis sur qu'il l'a finit étant donné que j'ai laissé mon ordinateur allumé plusieurs nuits pour cela, et le matin l'icône dans la barre des tâches avait disparu. Et il ré-apparaît à chaque démarrage.
Si je ne trouve pas de solution c'est ce que je vais finir par faire....

[FoolEcho]

Maintenant que tu en parles, j'ai aussi constaté ce comportement chez moi sans y prêter plus d'attention que ça (il ne me semble pas que nepomuk agissait comme ça précédemment, mais je ne pourrais pas le jurer).

Pourquoi tu ne décoche pas l'indexation de ce dossier.

Donc en attendant peut-être plus d'infos, si ça te pénalise: +1.
Ou si tu as le courage, tu rétrogrades kdebase-runtime/kdelibs pour voir si ça le faisait avant (passe par ARM). Il y a aussi une révision de kdelibs dans [testing], dès fois que.

[Emericn6k]

Pour rappel nepomuk nécessite a priori l'ajout de la ligne suivante dans /etc/sysctl.conf pour pouvoir suivre un grand nombre de fichiers à la fois :

Code : Tout sélectionner

fs.inotify.max_user_watches = 524288

Je ne sais pas si ça a un lien... Chez moi il n'y avait pas le souci, mais j'ai coupé nepomuk il y a quelques semaines parce que finalement, je suis encore trop old-school pour en avoir une réelle utilité.

Question de pure curiosité : pourquoi avoir installé Texlive dans le home?

[FoolEcho]

Je ne pense pas que ça soit lié.
D'autant que je suis tombé là dessus: http://userbase.kde.org/Nepomuk#Frequen ... _Questions

Q. Nepomuk re-indexes files at startup.

A. This bug has been fixed in 4.7.0 versions. Now Nepomuk just "scans" for changes, without indexing anything.

Sur ma session, il parle bien de réindexer quand il redémarre, donc, à moins d'une erreur de traduction, je penche pour une régression (il ne me semble pas qu'il faisait ça sur les 4.7.0 à 4.7.2 effectivement... éventuellement, je réinstallerai ces versions pour voir).

EDIT: ... quoique... il ne réindexe pas tout, c'est vrai.

[nicollivier]

@ FoolEcho: Tu as aussi le même problème avec un dossier en particulier ?!

@ Emericn6k: J'ai préféré le mettre dans mon home à l'époque où j'étais sur une distrib qu'il fallait mettre à jour tous les six mois. De cette façon je retrouve tous mes paquets comme avant.

[EDIT:] En fait il scanne "peut-être" tout mon /home à chaque fois.
Je dis peut-être car je viens de me rendre compte qu'il a scanné mon dossier "Documents" où se trouve le dossier pour LaTeX. Je vais essayer de regarder si il continue dans les autres dossiers de mon /home

[FoolEcho]

J'avais cru qu'il n'en regardait qu'une partie, mais il semble bien refaire le tour de tous les dossiers signalés comme à indexer selon la configuration qui est faite de nepomuk (j'ai autant de fichiers avant/après indexation dans nepomuk: 16183 pour info). Faudra voir ça de plus près (j'ai pas été voir sur le tracker de kde), je pense quand même que c'est le retour du bug que j'ai mentionné juste avant.


EDIT: j'ai repassé tout kde en 4.7.2 pour éviter tout souci, même si kdelibs est peut-être suffisant (via ARM à la date du 1 novembre) et cette fois, strigi démarre et reste en pause, n'ayant rien à faire.

Truc «amusant» au passage en repassant en 4.7.3: si on stoppe puis redémarre strigi, il recommence son cinéma de tout reprendre depuis le début...
Du coup, en attendant d'avoir une correction ou plus d'éléments pour éventuellement ouvrir un rapport de bug (j'ai bien vu deux bugs qui pourraient s'en rapprocher, quoique sur de vieilles versions: https://bugs.kde.org/show_bug.cgi?id=248621 et https://bugs.kde.org/show_bug.cgi?id=226895 ), je te suggère donc de ne pas démarrer strigi (mais évidemment si tu fais des recherches par étiquette c'est pas possible, auquel cas, il faudrait mettre un max de mémoire pour qu'il finisse au plus vite -- ceci dit je ne comprends pas vraiment car même en étiquettant pendant qu'il bosse, les modifications sont prises en compte instantanément sans problèmes ) ou de rétrograder.

[nicollivier]

Merci beaucoup pour ton message.

Pour l'instant je n'utilise pas encore l’étiquetage. Je suis justement en train de regarder comment cela fonctionne et comment je peux m'en servir, mais à vrai dire il n'y a pas beaucoup d'info là-dessus, ce qui est bien dommage car cela semble vraiment prometteur.

Sinon pour revenir à la version précédente de KDE, comment faut-il le faire sans créer de problème d'incompatibilité avec d'autres logiciels ( bien que je ne pense pas qu'il y a beaucoup de différence entre la version 2 et la 3 ).

[EDIT]: Je viens de lire le message que tu as rajouté dans le rapport de bug, et c'est à propos des infos que tu vois à la fermeture de la session, où est-ce que tu as trouvé ces infos?! J'ai regardé dans les logs (messages - kernel ), mais je n'ai rien trouvé.

[FoolEcho]

Pour l'instant je n'utilise pas encore l’étiquetage. Je suis justement en train de regarder comment cela fonctionne et comment je peux m'en servir, mais à vrai dire il n'y a pas beaucoup d'info là-dessus, ce qui est bien dommage car cela semble vraiment prometteur.

http://wiki.mandriva.com/fr/Magnum03_Nepomuk
http://fr.wikipedia.org/wiki/Strigi
http://docs.kde.org/stable/fr/kdebase-r ... index.html
En gros, l'idée est de rajouter tes propres étiquettes/notes/annotations sur tout type de fichiers pour une recherche plus poussée.
J'ai commencé à m'y mettre, je trouve ça plutôt pratique car l'organisation par répertoires a ces limites.

Sinon pour revenir à la version précédente de KDE, comment faut-il le faire sans créer de problème d'incompatibilité avec d'autres logiciels ( bien que je ne pense pas qu'il y a beaucoup de différence entre la version 2 et la 3 ).

Ça dépend comment tu as installé kde...
J'avais commencé par juste réinstaller la version précédente de kdelibs, ça résolvait le problème, mais kate couinait. Donc, plus proprement, je suis passé par ARM. Cf. Downgrade.
Tu rajoutes le serveur dans le mirrorlist à la date du 1er novembre, tu remets le système entier à cette date. Puis tu enlèves le miroir, tu rajoutes dans ton pacman.conf ou en ligne de commandes le fait que tu ignores le groupe kde, ou les paquets kde que tu veux, pour remettre le reste du système à jour, moins kde.

[EDIT]: Je viens de lire le message que tu as rajouté dans le rapport de bug et c'est à propos des infos que tu vois à la fermeture de la session, où est-ce que tu as trouvé ces infos?! J'ai regardé dans les logs (messages - kernel ), mais je n'ai rien trouvé.

Ce n'est pas moi.
Tu parles de https://bugs.kde.org/show_bug.cgi?id=248621#c7 ? Effectivement, cette personne est sous Arch en plus et confirme également ce problème (bien, bien, bien).
Il faut voir dans le log de session (~/.xsession-errors) à partir d'un tty pour avoir les messages à la déconnexion. Je ne me prononcerai pas sur son constat cependant (comme il le dit lui même d'ailleurs): principalement parce que relancer strigi en cours de session à le même effet (et nepomuk n'est pas arrêté à ce moment, ni ne crash).
Mais puisqu'il relance ce rapport de bug, je pense que je vais appuyer dans ce sens et rajouter ce que j'ai constaté.

[nicollivier]

Avant de passer sous Arch, j'étais sous Mandriva, j'avais déjà essayé plusieurs fois de me lancer dans l'aventure «nepomuk» mais je n'y suis jamais arrivé.
Le principe de regrouper tous les documents (contacts - docs - pages web) par projet me semble vraiment très intéressant.
Le problème c'est qu'il faut tagger tous docs, et là il y a du boulot

Concernant le fait de passer à la version précédente.... Je pense que je vais patienter encore un peu
Cela me semble un poil complex pour moi au regard de mon utilisation de nepomuk.

Concernant le bug, en effet c'est bien celui-là.
Le timing est vraiment trop parfait, c'est d'ailleurs pour cela que je pensais que cela venait de toi

Par contre je n'ai pas les mêmes messages d'erreur que lui...

[FoolEcho]

Le problème c'est qu'il faut tagger tous docs, et là il y a du boulot

À qui le dis-tu... au fur et à mesure, ça va, mais pour rattraper le retard, c'est la plaie.

Concernant le fait de passer à la version précédente.... Je pense que je vais patienter encore un peu
Cela me semble un poil complex pour moi au regard de mon utilisation de nepomuk.

Comme tu veux. Tu peux effectivement te contenter de désactiver strigi, voire nepomuk.

Par contre je n'ai pas les mêmes messages d'erreur que lui...

Moi, non plus. Mais je ne pense pas que ça vienne de là de toutes manières: cchez moi, strigi réindexe tout depuis le début même s'il est relancé durant une session kde et ce, même s'il avait fini auparavant (tu pourrais me le confirmer ? ). J'ai rajouté un commentaire sur le bugtracker à ce sujet. Vu que ça fonctionnait sur au moins la version précédente, ça devrait se corriger vite (je n'ai pas cherché davantage, ni cherché à compiler le git pour voir). On verra bien.

[benjarobin]

Pour information je confirme le problème pour mes 2 PC et je suis dans le même cas que FoolEcho, pas de crash...

[FoolEcho]

Bien noté.

[nicollivier]

Idem pour moi,
J'ai aussi créé un nouvel utilisateur, idem. En redémarrant "strigi" il recommence à indexer. Mais cette fois-ci cela va très vite comme le /home est vide

[FoolEcho]

Dernier commentaire en date sur le bugtracker par celui qui s'en occupe:

Do not confuse indexing with scanning for changes for which there simply is no technical solution at the moment.

Il dit donc que strigi ne réindexe pas mais vérifie juste s'il y a eu des changements ... je ne suis pas convaincu ou alors c'est très bourrin... admettons que la traduction fr est mauvaise quand on relance strigi, n'empêche qu'il ne me semble pas qu'il agissait ainsi sur les versions précédentes (ou alors peut-être n'y avait-il jamais de notifications, je n'ai pas fait gaffe à ça ? ... si j'ai le temps et le courage, j'irai rétrograder kde encore une fois, histoire de vérifier... )...


EDIT: après rétrogradation, il semble qu'en effet strigi se comporte de la même manière que sur la dernière version, sauf qu'il n'y a pas de notification systématique apparemment (donc on ne s'en rend compte que maintenant).

[nicollivier]

Je suis surpris que cela soit le même fonctionnement qu'avant.
Car je ne me souviens pas que j'avais autant de consommation de ressources à chaque redémarrage.

Cependant ce fonctionnement semble logique, il faut bien qu'il détermine les différents changement.

[Emericn6k]

Je déterre ce sujet parce que j'avais le même problème, version "grave" récemment (nepomuk-t qui prend bcp de mémoire ET de CPU)

Comme ça n'en finissait pas de réindexer à chaque session, j'ai supprimé le dossier suivant pour relancer l'indexation de zéro :

Code : Tout sélectionner

~/.kde4/share/apps/nepomuk/repository

à vrai dire je crois même que j'ai supprimé ~/.kde4/share/apps/nepomuk en entier.

Et bien aujourd'hui, je vais mieux

Enfin plus précisément, l'indexeur est au repos quasi tout le temps, la consommation de ressources en début de session est rapide et les changements sont pris en compte instantanéments ou presque.

Encore une fois, la rolling release a tendance à avoir quelques incompatibilités avec les évolutions de KDE, visiblement

[nicollivier]

Merci de l'info, je vais tester cela tout de suite

[FoolEcho]

Comme ça n'en finissait pas de réindexer à chaque session, j'ai supprimé le dossier suivant pour relancer l'indexation de zéro :

Code : Tout sélectionner

~/.kde4/share/apps/nepomuk/repository

à vrai dire je crois même que j'ai supprimé ~/.kde4/share/apps/nepomuk en entier.

Heu... j'arrive sans doute trop tard (j'ai bizarrement zappé ce sujet), mais en faisant ça, tu repars de zéro, donc si tu avais annoté/étiquetté certains de tes fichiers, ben «*pouf* a pu» (donc sans sauvegarde, ça craint).

Après, réindexer peut aller plus ou moins vite selon le nombre de fichiers qu'il y a à balayer.

Enfin plus précisément, l'indexeur est au repos quasi tout le temps, la consommation de ressources en début de session est rapide et les changements sont pris en compte instantanéments ou presque.

En fait, c'est probablement car tu indexes peu de choses (c'est de toutes manières le bon truc à faire: limiter les répertoires à indexer, voire carrément stopper nepomuk si tu ne t'en sers pas).