Re: Comment faire pour savoir ce qui rame sur une machine
On Tue, Dec 14, 2010 at 03:15:50PM +0100, Xavier Brochard wrote : Aurelien wrote: On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote : free -h me dit que -h n'est pas une option recevable. pardon c'est free -m les outils ont presques tous l'option -h pour format lisible par un humain, pas free... OK, dans tous les cas, 256Mo, partagés (32Mo - j'essaie 64Mo, là, pour voir si c'est mieux), donc 220Mo sont occupés de base. Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que c'était plus. 256 Mo sont assez pour XFCE, en fait pour toutes les interfaces graphiques de Lenny. C'est ce qu'il me semblait (je suis en Squeeze). Quelques idées: Comme on pense tout de suite à un problème de pilote graphique, as-tu essayé de démarrer avec le pilote graphique vesa ou le pilote framebuffer, pour voir si ça vient du SIS? Non, je vais tenter. Le premier noyau 2.6 est sorti en 2003. Tu devais donc être en 2.4 au début. Sur des postes plus anciens, ça peut faire une grosse différence, mais sur le tiens, quand même pas. En console aussi ça rame? Non, j'ai commencé en 2.6. Ce PC est de 2003, mais il est possible que je n'ai mis Debian (SID, à l'époque) dessus que début 2004. Pour le matériel: lspci -k (montre les drivers) Heu, c'est marrant, mais pour la carte vidéo, il n'y a pas de driver listé. C'est normal ? Et, en fait, il n'est pas listé dans lsmod, non plus. Il doit être en dur ? (je travaille avec un noyau Debian). et aussi lspci -vvv (tape lsci -vvv sortielspci.txt parce que c'est très long) OK, rien de neuf. Petit truc qui me met la puce à l'oreille aujourd'hui : j'utilise cette machine presqu'uniquement pour écrire des partitions et les lire, ainsi que lire des vidéos pour mes élèves de basse. J'utilise tuxguitar, qui est basé sur Java, et je me demande si c'est pas de là que vient le problème. Parce que là, j'ai démarré sans lancer ce paquet, et ça a l'air de tourner beaucoup mieux. OK, petit bilan, le PC vient de démarrer, XFCE4 lancé, un seul xfce4-term de lancé. $ free -m total usedfree 185 132 53 C'est déjà un peu chaud, j'en ai pas beaucoup sous le coude, mine de rien. top ordonné par la mémoire me donne le palmarès suivant : 9% = wicd-client (je ne savais pas que j'avais installé ça, pas trop d'intérêt en ce qui me concerne) 8.9% = xfdesktop (OK, ça je peux faire sauter) 8.7% = Xorg 6.3% = xfce4-terminal 5.6% = xfce4-panel 5.1% = xfce4-menu-plug 5% = xfvwm4 3.7% = wicd-monitor 3.5% = wicd 3.3% = xfce4-session 3.3% = Thunar (pourquoi ? je n'ai pas de navigateur de fichiers ouvert) 2.9% = xfce4-power-management 2.3% = xfce4-settings Grossièrement, XFCE4 bouffe quand même 55% de la RAM à lui tout seul, et wicd une quinzaine de pourcent. Je pense que je peux virer wicd, compte tenu que je ne me loggue que sur le même réseau à chaque fois, en ethernet, avec un bail DHCP permanent. Pour XFC4, je peux virer le bureau, mais virer le panel, etc. ça commence à pas ressembler à grand-chose, et donc autant repasser à openbox ou icewm. Bon, en tout cas merci de votre aide, je vais essayer de faire des choix plus économes. xavier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ie7uad$eq...@dough.gmane.org -- Aurélien -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101216083605.gb16...@sebkhachott.net
Re: Comment faire pour savoir ce qui rame sur une machine
Aurelien wrote: On Tue, Dec 14, 2010 at 03:15:50PM +0100, Xavier Brochard wrote : Aurelien wrote: On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote : Pour le matériel: lspci -k (montre les drivers) Heu, c'est marrant, mais pour la carte vidéo, il n'y a pas de driver listé. C'est normal ? non, tu as du le rater; il doit être une ou deux lignes sous VGA compatible controller Et, en fait, il n'est pas listé dans lsmod, non plus. Il doit être en dur ? (je travaille avec un noyau Debian). non, il n'est pas en dur, c'est Xorg qui le charge ou alors tu es en vesa (je _crois_ qu'il n'est pas indiqué) vesa est lent, et peut-être encore plus avec Java (pure supposition)? Petit truc qui me met la puce à l'oreille aujourd'hui : j'utilise cette machine presqu'uniquement pour écrire des partitions et les lire, ainsi que lire des vidéos pour mes élèves de basse. J'utilise tuxguitar, qui est basé sur Java, et je me demande si c'est pas de là que vient le problème. Parce que là, j'ai démarré sans lancer ce paquet, et ça a l'air de tourner beaucoup mieux. c'est possible que Java ou Tuxguitar soit mal configuré. c'est quel Java? celui de Sun ou celui de Gnu? Faut tout de même pas tout mettre sur le compte de Java: en 1996 déjà, avec un P120 MHz 16 Mo de Ram on disait Java c'est lent, ça ralentit. Aunjourd'hui on a des monstres. Même toi (comparativement). Sur le serveur d'à côté, un bi-octo-coeurs, 16 Go de Ram, disques SSD + disques SATA3 en RAID 10, un assistant me dit encore ça rame à cause de Java. Et la marmotte alors? Bref, vérifie la config, mais ce n'est pas Java en lui même. OK, petit bilan, le PC vient de démarrer, XFCE4 lancé, un seul xfce4-term de lancé. $ free -m total usedfree 185 132 53 C'est déjà un peu chaud, j'en ai pas beaucoup sous le coude, mine de rien. tu as oublié une ligne qui commence par -/+ buffers/cache une partie de la ram utilisée est en fait un cache pour accélérer les choses. C'est libéré à la demande. Par exemple, sur mon portable ça donne: total used free sharedbuffers cached Mem: 1883 1441442 0 96688 -/+ buffers/cache:657 1226 c'est à dire que j'ai encore 1226 Mo sous le coude, et pas 442. top ordonné par la mémoire me donne le palmarès suivant : 9% = wicd-client (je ne savais pas que j'avais installé ça, pas trop d'intérêt en ce qui me concerne) 8.9% = xfdesktop (OK, ça je peux faire sauter) 8.7% = Xorg 6.3% = xfce4-terminal 5.6% = xfce4-panel 5.1% = xfce4-menu-plug 5% = xfvwm4 3.7% = wicd-monitor 3.5% = wicd 3.3% = xfce4-session 3.3% = Thunar (pourquoi ? je n'ai pas de navigateur de fichiers ouvert) 2.9% = xfce4-power-management 2.3% = xfce4-settings Grossièrement, XFCE4 bouffe quand même 55% de la RAM à lui tout seul, et wicd une quinzaine de pourcent. non non non c'est mesuré à l'instant t (et mis à jour de façon discrète, pas en continu). ce n'est pas ce qui est consommé en permanence. CEa dit c'est qand même bizarre. Pour XFC4, je peux virer le bureau, mais virer le panel, etc. ça commence à pas ressembler à grand-chose, et donc autant repasser à openbox ou icewm. Un de mes clients est sur un Céléron 1,2GHz, 512 Mo de Ram. Le poste fait serveur de cients légers avec KDE 3.5.10, ils y a 6 utilisateurs simultanés dessus, plus des accès rdesktop, des serveurs samba, nfs, cups, httpd, plus une base de données en perl. Tu as plutôt un problème de configuration. Tu devrais vraiment tester avec un CD Live. Prend SystemRescueCD il a des options intéressantes pour le lancement de l'affichage graphique. Il a des utilitaires de test du matriel que tu peux lancer au lieu de booter le CD linux. xavier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/iecno7$5j...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Sylvain L. Sauvage wrote: Le mardi 14 décembre 2010 à 14:57:44, Xavier Brochard a écrit : cor...@free.fr wrote: quelle taille fait /var/log/messages ? : 22.528.080 octets 22 Mo, rien que ça! si tu veux l'effacer il faudra passer en mode mono utilisateur soit au démarrage, soit comme ça: ferme ta session graphique, logge-toi root en console, et tape telinit 1 (le chiffre un) ensuite tu efface /var/log/messages et tu redémarre rm /var/log/messages reboot Euh, quel intérêt de vouloir l’effacer sans l’avoir lu ? c'est vrai Et pourquoi redémarrer ? Il suffit de faire un killall -HUP syslogd après l’avoir effacé (en root). syslogd doit être le seul processus qui y écrit en le gardant ouvert. oui mais tu sais des fois on écrit trop vite :) xxx -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ieco2k$5j...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Aurelien wrote: Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de pouvoir le changer ? Je me rends compte qu'on a cherché des pistes au lieu de répondre directment à ta question. Voici 2 moyens: - les outils de test du matériel, via un cd live le plus souvent: The Ultimate Boot CD, SystemRescueCD, etc. - les outils d'audit qui vont tourner qq minutes pendant que tu te sers de ta bécane: oprofile, sysstat (sont dans Squeeze). Mais attention à l'interprétation des résultats! xavier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ied2up$qp...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Le 14/12/2010 09:36, Aurelien a écrit : Salut, Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du calcul numérique. Mais c'est la misère, il en chie à la moindre opération (même un clic droit). J'aimerais bien savoir ce qui déconne, car, a priori quand j'étais en thèse, il supportait ça relativement bien, et pour ce que je demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis pas sûr. Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de pouvoir le changer ? Merci. A plus tard. Salut, commence simple, regarde un top ou htop[1] pour voir si tu as un processus qui te pompe ton processeur. Vérifie quel pilote graphique tu utilises ( grep -i driver /var/log/Xorg.0.log ) et les éventuels problèmes qui y sont liés ( egrep '((WW)|(EE))' /var/log/Xorg.0.log ). Si tout baigne regarde l'utilisation du disque avec iotop[2] par exemple, son état de santé avec smart[3] (juste un indicateur, pas infaillible). Regarde /var/log/syslog pour détecter un problème récurrent. Après ce petit tour du propriétaire tu en sauras un peu plus long normalement. [1] http://www.linuxpedia.fr/doku.php/commande/htop_atop [2] http://www.linuxpedia.fr/doku.php/commande/iotop [3] http://linux-attitude.fr/post/soyez-encore-plus-a-lecoute-de-vos-disques -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4d073249.2010...@googlemail.com
Re: Comment faire pour savoir ce qui rame sur une machine
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du calcul numérique. Mais c'est la misère, il en chie à la moindre opération (même un clic droit). J'aimerais bien savoir ce qui déconne, car, a priori quand j'étais en thèse, il supportait ça relativement bien, et pour ce que je demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis pas sûr. Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de pouvoir le changer ? Quand ça rame c'est la ram... Blague à part, depuis ta thèse les choses ont du changer. Tu ne dis pas un mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est- ce la même qu'avant? et c'est quoi au fait? et quelle version? D'autre part es-tu sûr d'avoir assez de Ram et assez de swap? Sur les serveurs, je commence toujours par un petit w qui me donne l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram. Après, pour rester dans des trucs simples: dmesg | tail tail /var/log/syslog J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein avec df -h (quand /tmp est dans sa propre partition) ou sudo du -sh /tmp/* ... et bien sûr tout ce qu'a dit tv.debian Avec ça on arrive à savoir si c'est un manque de Ram, de swap, un /tmp en désordre, un processus qui part en vrille, etc. Et si tout est normal on s'interroge sur le matériel. Il y aussi une solution expresse: commencer avec un live-cd, adapté à la bécanne, pour voir si ça tourne bien. Par exemple une Knoppix de 2003 (kde 3.x, noyau 2.4, tourne très bien avec 128 Mo de Ram) ou la dernière Knoppix (elle est très allégée) ou encore SystemRescueCD, qu'on devrait toujours avoir sous la main. Les live-cd plantent assez vite si le matériel déconne, et quand ils tournent bien, on sait tout de suite que le problème vient du système installé. bon courage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ie7dbr$qe...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Merci de ce rappel utile. Avec la commande top, j'ai cette première ligne : PID USER PR NI VIRT RES SHR S %CPU%MEM TIME+ COMMAND 517 root 20 0 151m 23m 696 R92.1 3.0 12:49.14 kerneloops %CPU = 92,41% Pisteur d'erreurs noyau (« oops ») : kerneloops est un démon qui collecte des informations sur les plantages du noyau puis envoie la signature extraite au site web kerneloops.org pour une analyse statistique et une présentation aux développeurs du noyau Linux. Est-ce normal que le processus kerneloops occupe 92,41% du CPU ? Merci. Le mardi 14 décembre 2010, Xavier Brochard a écrit : Quand ça rame c'est la ram... Blague à part, depuis ta thèse les choses ont du changer. Tu ne dis pas un mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est- ce la même qu'avant? et c'est quoi au fait? et quelle version? D'autre part es-tu sûr d'avoir assez de Ram et assez de swap? Sur les serveurs, je commence toujours par un petit w qui me donne l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram. Après, pour rester dans des trucs simples: dmesg | tail tail /var/log/syslog J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein avec df -h (quand /tmp est dans sa propre partition) ou sudo du -sh /tmp/* ... et bien sûr tout ce qu'a dit tv.debian Avec ça on arrive à savoir si c'est un manque de Ram, de swap, un /tmp en désordre, un processus qui part en vrille, etc. Et si tout est normal on s'interroge sur le matériel. Il y aussi une solution expresse: commencer avec un live-cd, adapté à la bécanne, pour voir si ça tourne bien. Par exemple une Knoppix de 2003 (kde 3.x, noyau 2.4, tourne très bien avec 128 Mo de Ram) ou la dernière Knoppix (elle est très allégée) ou encore SystemRescueCD, qu'on devrait toujours avoir sous la main. Les live-cd plantent assez vite si le matériel déconne, et quand ils tournent bien, on sait tout de suite que le problème vient du système installé. bon courage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201012141047.49307.cor...@free.fr
Re: Comment faire pour savoir ce qui rame sur une machine
Le 14/12/2010 10:47, cor...@free.fr a écrit : Merci de ce rappel utile. Avec la commande top, j'ai cette première ligne : PID USER PR NI VIRT RES SHR S %CPU%MEM TIME+ COMMAND 517 root 20 0 151m 23m 696 R92.1 3.0 12:49.14 kerneloops %CPU = 92,41% Pisteur d'erreurs noyau (« oops ») : kerneloops est un démon qui collecte des informations sur les plantages du noyau puis envoie la signature extraite au site web kerneloops.org pour une analyse statistique et une présentation aux développeurs du noyau Linux. Est-ce normal que le processus kerneloops occupe 92,41% du CPU ? Merci. Pas normal du tout, dans un premier temps tu peux tuer kerneloops, ensuite il faut trouver pourquoi il se lance à chaque démarrage (si c'est bien le cas). Cherche le crash noyau qui lance le oops dans dmesg, /var/log/messages (et /var/log/kern.log). Enfin le comportement de kerneloops ressemble à un bon gros bug, quelle taille fait /var/log/messages ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4d0747db.2000...@googlemail.com
Re: Comment faire pour savoir ce qui rame sur une machine
tv.deb...@googlemail.com wrote: Le 14/12/2010 10:47, cor...@free.fr a écrit : Avec la commande top, j'ai cette première ligne : PID USER PR NI VIRT RES SHR S %CPU%MEM TIME+ COMMAND 517 root 20 0 151m 23m 696 R92.1 3.0 12:49.14 kerneloops %CPU = 92,41% Est-ce normal que le processus kerneloops occupe 92,41% du CPU Pas normal du tout, dans un premier temps tu peux tuer kerneloops, A mon avis, il y a un rapport en cours, qui merde. Ça m'est arrivé aussi. C'est quoi ton noyau (uname -a)? Arrête kerneloops avec /etc/init.d/kerneloops stop puis relance le pour voir. ensuite il faut trouver pourquoi il se lance à chaque démarrage C'est normal. Il est lancé par défaut depuis un bout de temps déjà. Tu peux t'en passer, c'est surtout de l'aide pour les développeurs noyaux. Désactive le dans /etc/rc2.d xxx -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ie7hue$hr...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Salut, Je mixe vos deux réponses. On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote : Quand ça rame c'est la ram... Ah. Bon, bah Blague à part, depuis ta thèse les choses ont du changer. Oui, c'est sûr. Tu ne dis pas un mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est- ce la même qu'avant? et c'est quoi au fait? et quelle version? D'autre part es-tu sûr d'avoir assez de Ram et assez de swap? L'interface graphique, enfin, le gestionnaire de fenêtre et de bureau, c'est XFCE4, version 4.6.2. Auparavant j'utilisais icewm, il est vrai. La carte vidéo est une carte vidéo SiS. Au niveau RAM, j'ai (a priori, d'après free et top) 256 Mo. Je me rappelle que c'est partagé avec la vidéo. J'avais souvenir de 512Mo, mais c'est un souvenir (enfin, ça pourrait expliquer le pourquoi). Au niveau swap : 1Go, ça devrait suffire ! Sur les serveurs, je commence toujours par un petit w qui me donne l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram. Après, pour rester dans des trucs simples: Je n'ai pas compris l'histoire du w pour l'uptime, mais de toute façon, j'ai allumé le PC il n'y a pas longtemps. free -h me dit que -h n'est pas une option recevable. free tout court me dit qu'il me reste 4Mo de RAM libre (outch !). J'ai des programmes de lancés. dmesg | tail tail /var/log/syslog Rien de particulier. J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein avec df -h (quand /tmp est dans sa propre partition) ou sudo du -sh /tmp/* /tmp utilisé à 2%. tv.debian a ecrit : commence simple, regarde un top ou htop[1] pour voir si tu as un top me donne le processus le plus groumand à 6% de CPU et java (tuxguitar) bouffe 12.5% de la RAM. processus qui te pompe ton processeur. Vérifie quel pilote graphique tu utilises ( grep -i driver /var/log/Xorg.0.log ) Driver SiS900. et les éventuels problèmes qui y sont liés ( egrep '((WW)|(EE))' /var/log/Xorg.0.log ). Rien. Si tout baigne regarde l'utilisation du disque avec iotop[2] par exemple, son état de santé avec smart[3] (juste un indicateur, pas infaillible). Pas le net sur la machine pour l'instant, et pas ces paquets là d'installés. Je regarderai tout à l'heure. Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que c'était plus. Regarde /var/log/syslog pour détecter un problème récurrent. Rien de particulier. Merci en tout cas. -- Aurélien -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101214120544.gb4...@sebkhachott.net
Re: Comment faire pour savoir ce qui rame sur une machine
Avec la commande top, j'ai cette première ligne : PID USER PR NI VIRT RES SHR S %CPU%MEM TIME+ COMMAND 517 root 20 0 151m 23m 696 R92.1 3.0 12:49.14 kerneloops %CPU = 92,41% --- Pas normal du tout, dans un premier temps tu peux tuer kerneloops, A mon avis, il y a un rapport en cours, qui merde. Ça m'est arrivé aussi. C'est quoi ton noyau (uname -a) ? : Noyau = 2.6.26-2-686 Arrête kerneloops avec /etc/init.d/kerneloops stop puis relance le pour voir. ensuite il faut trouver pourquoi il se lance à chaque démarrage C'est normal. Il est lancé par défaut depuis un bout de temps déjà. Tu peux t'en passer, c'est surtout de l'aide pour les développeurs noyaux. Désactive le dans /etc/rc2.d : OK, fait. (arrêté) Il était bien lancé via /etc/rc2.d = mis en K (kill). --- Pas normal du tout, dans un premier temps tu peux tuer kerneloops, ensuite il faut trouver pourquoi il se lance à chaque démarrage (si c'est bien le cas). Cherche le crash noyau qui lance le oops dans dmesg, /var/log/messages (et /var/log/kern.log) : Aucune info sur oops ou kerneloops dans ces 2 fichiers. Enfin le comportement de kerneloops ressemble à un bon gros bug, quelle taille fait /var/log/messages ? : 22.528.080 octets Merci ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201012141322.24580.cor...@free.fr
Re: Comment faire pour savoir ce qui rame sur une machine
cor...@free.fr wrote: quelle taille fait /var/log/messages ? : 22.528.080 octets 22 Mo, rien que ça! si tu veux l'effacer il faudra passer en mode mono utilisateur soit au démarrage, soit comme ça: ferme ta session graphique, logge-toi root en console, et tape telinit 1 (le chiffre un) ensuite tu efface /var/log/messages et tu redémarre rm /var/log/messages reboot xavier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ie7t8f$8v...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Aurelien wrote: On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote : free -h me dit que -h n'est pas une option recevable. pardon c'est free -m les outils ont presques tous l'option -h pour format lisible par un humain, pas free... Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que c'était plus. 256 Mo sont assez pour XFCE, en fait pour toutes les interfaces graphiques de Lenny. Quelques idées: Comme on pense tout de suite à un problème de pilote graphique, as-tu essayé de démarrer avec le pilote graphique vesa ou le pilote framebuffer, pour voir si ça vient du SIS? Le premier noyau 2.6 est sorti en 2003. Tu devais donc être en 2.4 au début. Sur des postes plus anciens, ça peut faire une grosse différence, mais sur le tiens, quand même pas. En console aussi ça rame? Pour le matériel: lspci -k (montre les drivers) et aussi lspci -vvv (tape lsci -vvv sortielspci.txt parce que c'est très long) xavier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/ie7uad$eq...@dough.gmane.org
Re: Comment faire pour savoir ce qui rame sur une machine
Le mardi 14 décembre 2010, Xavier Brochard a écrit : cor...@free.fr wrote: quelle taille fait /var/log/messages ? : 22.528.080 octets -- 22 Mo, rien que ça! si tu veux l'effacer il faudra passer en mode mono utilisateur soit au démarrage, soit comme ça: ferme ta session graphique, logge-toi root en console, et tape telinit 1 (le chiffre un) ensuite tu efface /var/log/messages et tu redémarre rm /var/log/messages = reboot. xavier --- C'est fait et merci ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201012141717.45849.cor...@free.fr
Re: Comment faire pour savoir ce qui rame sur une machine
Le mardi 14 décembre 2010 à 14:57:44, Xavier Brochard a écrit : cor...@free.fr wrote: quelle taille fait /var/log/messages ? : 22.528.080 octets 22 Mo, rien que ça! si tu veux l'effacer il faudra passer en mode mono utilisateur soit au démarrage, soit comme ça: ferme ta session graphique, logge-toi root en console, et tape telinit 1 (le chiffre un) ensuite tu efface /var/log/messages et tu redémarre rm /var/log/messages reboot Euh, quel intérêt de vouloir l’effacer sans l’avoir lu ? Et pourquoi redémarrer ? Il suffit de faire un killall -HUP syslogd après l’avoir effacé (en root). syslogd doit être le seul processus qui y écrit en le gardant ouvert. -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201012142005.40662.sylvain.l.sauv...@free.fr
