[cron] utilité du script man-db ?

Elbarto · Message par **Elbarto** » lun. 17 juin 2013, 10:29

Bonjour,

dans /etc/cron.daily/ il y a un script qui est installé par archlinux : man-db,

man-db se lance chaque jour et fait ramer mon portable car il utilise massivement le disque dur pendant 5 minutes, est-ce que ce script est vraiment utile ?

peut-on le supprimer sans inconvénients ?

Message par **benjarobin** » lun. 17 juin 2013, 10:57

man-db ne devrait tourner que si les pages du manuel ont changés...
Il faudrait voir les log de cron

Elbarto · Message par **Elbarto** » lun. 17 juin 2013, 22:41

mais justement pour savoir s'il y a eu ajout de fichiers d'aide man-db est bien obligé de parcourir le disque dur pour voir si des choses ont été ajoutées, ensuite s'il y a des modifications à faire il lancera un script update-db de mémoire,

comme mon disque dur est très lent ( disque dur 2.5 pouces IDE 5400 tours ) man-db sature la bande-passante, il ne reste plus grand chose pour les autres applications pendant les 5 minutes de son scan intégral du disque dur d'où la lenteur

Message par **benjarobin** » lun. 17 juin 2013, 23:51

Tu mélanges update-db qui n'a rien à voir avec man-db.
Je veux bien croire que update-db ralentisse ton PC un peu, par contre man-db c'est très étrange

Elbarto · Message par **Elbarto** » mar. 18 juin 2013, 00:25

voici le contenu de crond.log, rien d'anormal à priori

Code : Tout sélectionner

Jun 17 10:01:02 localhost anacron[1065]: Will run job `cron.daily' in 18 min.
Jun 17 10:01:02 localhost anacron[1065]: Will run job `cron.weekly' in 38 min.
Jun 17 10:01:02 localhost anacron[1065]: Jobs will be executed sequentially
Jun 17 10:19:02 localhost anacron[1065]: Job `cron.daily' started
Jun 17 10:25:26 localhost anacron[1065]: Job `cron.daily' terminated (mailing output)
Jun 17 10:25:26 localhost anacron[1065]: Can't find sendmail at /usr/sbin/sendmail, not mailing output
Jun 17 10:39:02 localhost anacron[1065]: Job `cron.weekly' started
Jun 17 10:39:03 localhost anacron[1065]: Job `cron.weekly' terminated
Jun 17 10:39:03 localhost anacron[1065]: Normal exit (2 jobs run)

je suis sûr que c'est man-db qui ralentit le portable, car quand je fais un "top" je vois bien que man-db s'execute pendant au moins 5 minutes avec la led du disque dur constamment allumée, puis je vois ensuite parfois update-db mais qui lui reste très peu de temps après man-db,

quand je lance la commande "mandb" en mode root il n'y a pas de souci, il s'execute en moins de 10 secondes,

voici le contenu du script crond "man-db", il y a peut-être un bug dans ce script qui force la recréation de la base de données :

Code : Tout sélectionner

#!/bin/sh

# nicenesses range from -20 (most favorable scheduling) to 19 (least favorable)
NICE=19

# 0 for none, 1 for real time, 2 for best-effort, 3 for idle
IONICE_CLASS=2

# 0-7 (for IONICE_CLASS 1 and 2 only), 0=highest, 7=lowest
IONICE_PRIORITY=7

UPDATEMANDB="/usr/bin/mandb --quiet"

# Update the "whatis" database
#/usr/bin/makewhatis -u -w

# taken from Debian
# man-db cron daily
set -e

if ! [ -d /var/cache/man ]; then
    # Recover from deletion, per FHS.
    mkdir -p /var/cache/man
    chmod 755 /var/cache/man
fi

# regenerate man database

if [ -x /usr/bin/nice ]; then
  UPDATEMANDB="/usr/bin/nice -n ${NICE:-19} ${UPDATEMANDB}"
fi

if [ -x /usr/bin/ionice ]; then
  UPDATEMANDB="/usr/bin/ionice -c ${IONICE_CLASS:-2} -n ${IONICE_PRIORITY:-7} ${UPDATEMANDB}"
fi

${UPDATEMANDB}

exit 0

edit: j'ai tenté de récréer la base de données au cas où elle serait corrompue :

Code : Tout sélectionner

mandb -c

Message par **benjarobin** » mar. 18 juin 2013, 09:54

Alors top ne t'indiquera absolument pas le programme qui utilise le disque dur, utilise iotop (à lancer en root)
Si tu veux vraiment tester lance manuellement le script cron : /etc/cron.daily/man-db

Elbarto · Message par **Elbarto** » mar. 18 juin 2013, 22:03

ce qui est sûr c'est que c'est man-db qui fait mouliner le disque dur, aucun doute là dessus même si "top" indique surtout le %CPU, j'ai rencontré tellement de fois le problème que je n'ai plus de doutes ( j'avais aucun autre processus qui martyrisait le disque à part man-db ),

je pense que c'est lié aux options du script cron ( les IONICE_CLASS, les IONICE_PRIORITY ), je vais essayer de recréer un script crond bien plus simple et moins fouilli que l'officiel, puis tester les 2 scripts

Message par **benjarobin** » mar. 18 juin 2013, 22:09

Les options comme tu dit permet de diminuer la priorité sur l’utilisation du disque dur et donc te permettre d'utiliser le PC alors que le script tourne
Sinon on ne peut pas faire plus simple comme script.
Peux tu nous donner la sortie (en root) de ceci

Code : Tout sélectionner

cp /etc/cron.daily/man-db /tmp
sed -i "s|--quiet||" /tmp/man-db
time /tmp/man-db

Elbarto · Message par **Elbarto** » mar. 18 juin 2013, 23:05

j'ai executé manuellement le script man-db, il tourne en moins de 5 secondes,

puis j'ai fait tes manips, execution très rapide du script modifié :

Code : Tout sélectionner

Effacement des entrées inutiles de /usr/share/man en cours…
Traitement des pages du manuel sous /usr/share/man…
Effacement des entrées inutiles de /usr/share/man/hu en cours…
Traitement des pages du manuel sous /usr/share/man/hu…
Effacement des entrées inutiles de /usr/share/man/pl en cours…
Traitement des pages du manuel sous /usr/share/man/pl…
Effacement des entrées inutiles de /usr/share/man/zh_CN en cours…
Traitement des pages du manuel sous /usr/share/man/zh_CN…
Effacement des entrées inutiles de /usr/share/man/fr en cours…
Traitement des pages du manuel sous /usr/share/man/fr…
Effacement des entrées inutiles de /usr/share/man/tr en cours…
Traitement des pages du manuel sous /usr/share/man/tr…
Effacement des entrées inutiles de /usr/share/man/da en cours…
Traitement des pages du manuel sous /usr/share/man/da…
Effacement des entrées inutiles de /usr/share/man/es en cours…
Traitement des pages du manuel sous /usr/share/man/es…
Effacement des entrées inutiles de /usr/share/man/de en cours…
Traitement des pages du manuel sous /usr/share/man/de…
Effacement des entrées inutiles de /usr/share/man/pt_BR en cours…
Traitement des pages du manuel sous /usr/share/man/pt_BR…
Effacement des entrées inutiles de /usr/share/man/jp en cours…
Traitement des pages du manuel sous /usr/share/man/jp…
Effacement des entrées inutiles de /usr/share/man/ja en cours…
Traitement des pages du manuel sous /usr/share/man/ja…
Traitement des pages du manuel sous /usr/share/man/cat1…
Effacement des entrées inutiles de /usr/share/man/nl en cours…
Traitement des pages du manuel sous /usr/share/man/nl…
Effacement des entrées inutiles de /usr/share/man/pl.UTF-8 en cours…
Traitement des pages du manuel sous /usr/share/man/pl.UTF-8…
Effacement des entrées inutiles de /usr/share/man/ko en cours…
Traitement des pages du manuel sous /usr/share/man/ko…
Effacement des entrées inutiles de /usr/share/man/cs en cours…
Traitement des pages du manuel sous /usr/share/man/cs…
Traitement des pages du manuel sous /usr/share/man/cat3…
Effacement des entrées inutiles de /usr/share/man/de.UTF-8 en cours…
Traitement des pages du manuel sous /usr/share/man/de.UTF-8…
Effacement des entrées inutiles de /usr/share/man/ru en cours…
Traitement des pages du manuel sous /usr/share/man/ru…
Effacement des entrées inutiles de /usr/share/man/it en cours…
Traitement des pages du manuel sous /usr/share/man/it…
Effacement des entrées inutiles de /usr/share/man/sv en cours…
Traitement des pages du manuel sous /usr/share/man/sv…
Effacement des entrées inutiles de /usr/share/man/fr.UTF-8 en cours…
Traitement des pages du manuel sous /usr/share/man/fr.UTF-8…
Effacement des entrées inutiles de /usr/share/man/id en cours…
Traitement des pages du manuel sous /usr/share/man/id…
Effacement des entrées inutiles de /usr/share/man/zh_TW en cours…
Traitement des pages du manuel sous /usr/share/man/zh_TW…
Effacement des entrées inutiles de /usr/share/man/sl en cours…
Traitement des pages du manuel sous /usr/share/man/sl…
Traitement des pages du manuel sous /usr/local/man…
Un sous-répertoire de manuel contient de nouvelles pages.
Une page de manuel a été ajoutée.
Une page sans source a été ajoutée.
Une entrée inutile de la base a été supprimée.

real    0m3.962s
user    0m1.073s
sys     0m0.173s

je continue à penser que les merdes viennent des options du script, un truc lié aux priorités/multitaches, ça doit merder avec crond/nice quand certaines circonstances sont rencontrées ( genre il y a une activité disque parrallèle et là des bugs apparaissent, instinctivement c'est ce que je sens, surtout que le script original contient des if avec des chmod, c'est pour ça que je parlais de créer un script crond encore plus simple avec juste une ligne qui lance "mandb" )

Message par **benjarobin** » mar. 18 juin 2013, 23:40

Il n'est pas possible de plus simplifier ce script, c'est le strict minimum... Il est très bien, et il fonctionne très bien.
Tu m'assures que c'est man-db qui est lent et moi je te dit que ce n'est pas le cas... Entre 5s et 5 minutes il y a un fossé...
Installe iotop et tu vérifiera quand c'est lent qui est le coupable

Je pense qu'il y a bien une activité du disque parallèle qui ralentie le PC, et comme le script est configuré pour réaliser l'action uniquement quand il n'y a pas d'activité du disque, il se peut que man-db prenne plusieurs minutes, mais ce n'est pas pour autant lui le coupable. iotop te le donnera

Tu es têtu mais moi encore plus

(Après je peux me tromper, mais c'est plus simple de faire le test que de discuter théorie inutilement

)

mélodie · Message par **mélodie** » mer. 19 juin 2013, 00:26

J'ai appris quelque chose, je ne connaissais pas iotop.

Quelle est la colonne la plus à gauche ? Je crois que je lis "TID" ?

Message par **benjarobin** » mer. 19 juin 2013, 00:34

TID = Thread id.
Pour information, l'id du thread principal est égale au PID (processus ID), et un processus peut avoir plusieurs threads "secondaires"

Message par **FoolEcho** » mer. 19 juin 2013, 09:08

benjarobin a écrit :Je pense qu'il y a bien une activité du disque parallèle qui ralentie le PC, et comme le script est configuré pour réaliser l'action uniquement quand il n'y a pas d'activité du disque, il se peut que man-db prenne plusieurs minutes, mais ce n'est pas pour autant lui le coupable. iotop te le donnera

+1 (p't'êt' qu'un avis en plus incitera Elbarto).

Elbarto · Message par **Elbarto** » mer. 19 juin 2013, 22:30

je vais continuer les investigations

pour l'instant les tests de ce topic n'ont consisté qu'à lancer manuellement mandb et le script, là je vais maintenant attendre que cron lance lui même le script pendant que j'utilise le PC ( surf internet, bureautique ) histoire que le bug se recrée, je pourrai alors mieux analyser ce qui se passe,

à noter qu'un autre topic similaire existe mais je n'ai pas compris sa résolution :

http://forums.archlinux.fr/topic5318.html

Message par **FoolEcho** » jeu. 20 juin 2013, 09:07

Elbarto a écrit :pour l'instant les tests de ce topic n'ont consisté qu'à lancer manuellement mandb et le script

Pour l'instant les tests sur lesquels tu te focalises n'ont consisté qu'à lancer manuellement mandb et le script... car benjarobin t'a proposé autre chose avec une très bonne (et sans doute la bonne) explication: man-db n'est qu'un symptôme (dans l'autre sujet -- par ailleurs très vieux et avec [testing], c'est du contournement: lancer la tâche cron une fois par semaine).

Elbarto · Message par **Elbarto** » jeu. 20 juin 2013, 12:24

on se moque mais si ça se trouve je suis en train de mettre le doigt sur un bug pernicieux que personne chez arch n'a encore remarqué

j'ai aussi une machine virtuelle archlinux sur un PC beaucoup plus puissant ( mais avec la même configuration au niveau des paquets, bureau KDE, les mêmes applications, il y a donc moyen aussi de récréer le problème )

Elbarto · Message par **Elbarto** » jeu. 20 juin 2013, 21:38

je viens de faire un "time mandb" sur ma machine virtuelle, le record de lenteur a été battu :

Code : Tout sélectionner

real    7m6.261s
user    2m29.537s
sys     2m52.080s

pas mal d'erreurs de ce type qui ralentissent mandb :

Code : Tout sélectionner

mandb: attention : /usr/share/man/man5/modules.dep.bin.5.gz : lien symbolique ou directive ROFF « .so » incorrect
Mise à jour du cache d'index pour le chemin « /usr/share/man/man3 ». Attendez…mandb: impossible d'ouvrir /usr/share/man/afSeekFrame.3: Aucun fichier ou dossier de ce type
mandb: attention : /usr/share/man/man3/afTellFrame.3.gz : lien symbolique ou directive ROFF « .so » incorrect

j'ai fait un iotop et seul mandb utilise le disque pendant tout ce temps là,

je vais tenter un "mandb -c" pour voir si la re-création de la base résout le problème de lenteur

edit: ça résout le problème

Code : Tout sélectionner

real    0m0.769s
user    0m0.467s
sys     0m0.220s

il se peut donc qu'on soit obligé de purger la base en demandant régulièrement à man-db de récréer la base pour éviter ces lenteurs,

ça me rappelle le problème que j'ai eu avec pacman quand je faisais un pacman -Syu, il mettait des plombes à lire la base de données, un "pacman-optimize" était la solution pour améliorer considérablement la réactivité de pacman ( il reconstruisait la base ),

visiblement mandb supporte mal que la base soit trop ancienne, il a besoin de temps en temps d'une reconstruction ( mandb -c ) pour virer les merdes et les entrées incohérentes qui ralentissaient son scan ( et qui entrainaient d'énormes ralentissements sur un vieux pc portable équipé d'un disque IDE lent )

Message par **tuxce** » ven. 21 juin 2013, 10:33

Elbarto a écrit : il se peut donc qu'on soit obligé de purger la base en demandant régulièrement à man-db de récréer la base pour éviter ces lenteurs,

Ce n'est pas cohérent avec le résultat que t'as eu la veille :

Elbarto a écrit :j'ai executé manuellement le script man-db, il tourne en moins de 5 secondes,

T'aurais pas un souci d'espace disque ? dans /var en particulier ?

Elbarto · Message par **Elbarto** » ven. 21 juin 2013, 12:10

faut bien respecter la chronologie des messages dans ce topic

j'avais testé sur un portable dont j'avais déjà fait un "mandb -c" auparavant donc normal qu'il soit rapide,

et hier j'avais testé pour la première fois sur une machine virtuelle où je n'avais pas encore fait de "mandb -c", d'où la lenteur,

après le "mandb -c" tout s'execute beaucoup plus rapidement

Elbarto · Message par **Elbarto** » mer. 26 juin 2013, 10:42

bon ben c'est toujours pas résolu finalement,

le problème c'est que quand cron lance le script man-db sur mon portable j'ai toujours 5~6 minutes de scan par mandb, c'est beaucoup trop lent,

j'ai utilisé iotop et il y a rien d'autres qui utilise le disque dur à part mandb ( un taux de 15 à 150 ko/sec comme débit affiché par iotop )

je crois que je vais finir par désactiver ce script man-db faute d'avoir résolu ce bug,

à noter que quand je lance manuellement le script il n'y a pas de problèmes de lenteur, c'est uniquement lorsque c'est crond qui lance le script que ça met un temps fou à s'executer

Arch Linux

Archlinux.fr [Forums]

[cron] utilité du script man-db ?

[cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ?

Re: [cron] utilité du script man-db ? (résolu)

Re: [cron] utilité du script man-db ? (résolu)

Re: [cron] utilité du script man-db ?