Re: Reboot intempestifs
Suite et fin. Ce week-end j'ai testé une autre alimentation, cela n'a rien changé. J'ai pu me rendre compte que j'avais en fait 2 barettes et que mon lshw avait bel et bien dit vrai la première fois. Une barette de 128Mo et une de 64Mo. La 64 semblait flinguée. J'ai testé divers emplacements mais niet. Au final, il y avait un peu poussière... j'ai aspiré tout ça, et je pense que j'ai dû faire mon bourrin. Résultat plus rien au démarrage. juste un toc toc toc toc toc dans le haut parleur. Donc j'ai soit achevé la carte mère, soit mes barettes. Sans doute en laissant branché le ventilateur du processeur au moment de l'aspiration de la poussière. Bref, j'ai récupéré une autre carte mère avec 512Mo de ram et après quelques galère de grub (error 18) et un flashage de bios, c'est reparti comme en 40! Je n'ai plus aucun problème de reboot et j'ai pu installer munin. Donc le souci était bien hardware et cela venait très probablement de la ram. J'ai au final changé : processeur, carte mère et ram (et carte graphique car j'avais la flemme de les échanger). J'ai conservé les disques, les cartes réseau et l'alim. J'ai d'ailleurs était étonné de voir que ma debian gère cela sans problème, elle n'a même pas sourcillé. Enfin, je tiens à vous remercier pour tous vos conseils et toutes vos astuces! Bon appetit. -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Vincent H. a écrit : Bonjour et merci pour ta réponse. On 10/22/07, Jean-Yves F. Barbier <[EMAIL PROTECTED]> wrote: c'est memtest86+ qu'il faut installer; par ailleurs, il existe en image iso bootable pour tests Oui c'est ce que j'ai installé. J'ai testé ma RAM pendant 8h30, 17 passes de tests effectuées avec succès (0 erreur). (mais il ne découvre pas tout: il a fallu que je pousse la RAM au maximum pour découvrir que la corruption du fs venait de la barette#2, qui ne faisait pas d'erreurs à vitesse normale) Ah? Qu'entends-tu par pousser la RAM au maximum? J'ai booté sur memtest86+ et j'ai laissé tourné les tests. J'ai regardé les réglages rapidement et j'ai le souvenir qu'on pouvait modifier la taille de la ram à tester, mais il me semble que par défaut le logiciel teste toute la ram, non? sur la CM que je testais, le BIOS offrait la poss. de différents timings: Normal, Fast, Turbo, 10ns, 8ns, j'ai vérifié que chaque barette tenait aussi le 2-2-x en démarrant avec une seule barette et en regardant ce que memtest indiquait comme chiffres) et j'ai tout mis au plus petit; et c'est là que les erreurs sont apparues (en mode normal, aléatoires et dès fois rien en 9h de burn-in, mais nombreuses et dès le test 3 (ou 4, sais'pu) en étant poussées). Par ailleurs, n'oublie pas que les premiers 108KB ne sont pas testés puisqu'ils servent à héberger le programme memtest (mais tu peux ruser en intervertissant 2 barettes; c'est le propre de l'homme: il est pervert envers les petits programmes :) JY -- I continued wetting my bed for a long time, not just out of contrariness, but to have the pleasure of feeling my warm urine running down my legs and wallowing in its odor. -- Salvador Dali
Re: Reboot intempestifs
Bonjour et merci pour ta réponse. On 10/22/07, Jean-Yves F. Barbier <[EMAIL PROTECTED]> wrote: > c'est memtest86+ qu'il faut installer; par ailleurs, il existe en > image iso bootable pour tests Oui c'est ce que j'ai installé. J'ai testé ma RAM pendant 8h30, 17 passes de tests effectuées avec succès (0 erreur). > (mais il ne découvre pas tout: il > a fallu que je pousse la RAM au maximum pour découvrir que la corruption > du fs venait de la barette#2, qui ne faisait pas d'erreurs à vitesse normale) > Ah? Qu'entends-tu par pousser la RAM au maximum? J'ai booté sur memtest86+ et j'ai laissé tourné les tests. J'ai regardé les réglages rapidement et j'ai le souvenir qu'on pouvait modifier la taille de la ram à tester, mais il me semble que par défaut le logiciel teste toute la ram, non? Je vais également aller jeter un oeil sur /var/lib/dpkg/available -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
c'est memtest86+ qu'il faut installer; par ailleurs, il existe en image iso bootable pour tests (mais il ne découvre pas tout: il a fallu que je pousse la RAM au maximum pour découvrir que la corruption du fs venait de la barette#2, qui ne faisait pas d'erreurs à vitesse normale) Vincent H. a écrit : On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: Un petit coup de memtest86++ permettrait d'en savoir plus. Est-il possible de booter sur memtest86, faire une serie de test (qui log le tout quelque part) et ensuite rebooter automatiquement le serveur pour me permettre d'avoir à nouveau la main et finalement étudier les logs? J'ai installé memtest86, il s'est à priori rajouté tout seul dans grub (j'ai pas eu le temps de lire le fichier menu.lst en entier mais j'ai pu trouver un memtest86 dedans) -- #if _FP_W_TYPE_SIZE < 32 #error "Here's a nickel kid. Go buy yourself a real computer." #endif -- linux/arch/sparc64/double.h
Re: Reboot intempestifs
j'ai aussi ce type de PB sur une CM ECS, et je ne suis pas loin de me dire que, puisque toutes les RAMs ont été changées, il ne reste plus que les HDs ou la CM (j'ai régulièrement un ou deux caractères qui merdouillent dans /var/lib/dpkg/available (et/ou status)) ça arrive dès fois après une pêche électrique Vincent H. a écrit : On 10/23/07, Jean-Michel OLTRA <[EMAIL PROTECTED]> wrote: Bonjour, Bonjour et merci de ta réponse, Si tu as plusieurs barettes, essaie de les retirer une à une. J'ai déjà eu ce problème de reboot intempestif. C'était tout bonnement une barette mémoire défectueuse. Alors en fait j'ai vérifié hier soir et je n'ai bien qu'une seule barrete de 128 Mo. J'ai éxecuté memtest86+ toute la nuit: 8h30 de tests, 17 passes éxecutées avec succès : 0 erreur. Que faire? J'ai regardé un peu les logs de webmin qui m'avait l'air un peu suspect, je l'ai donc purement et simplement desinstallé lui aussi car je ne m'en sers plus depuis des mois. J'ai éteint les autres machines de mon réseau local, mais cela ne change rien. Est-il possible de faire rebooter une machine en la spammant sur le net? Ai-je un moyen de vérifier cela? D'autres log peuvent-ils m'aider à comprendre ces reboots? Je ne sais plus trop où chercher là :-/ Pour rappel, au niveau du hardware, j'ai refait mon swap avec vérification des blocs défectueux (résultat: aucun bloc défectueux), testé ma ram toute la nuit (0 erreur), et j'ai fait également de la place sur / (~ 3Go). Niveau software: désinstallation de munin et de ses dépendances. désinstallation de webmin. Je suis un peu perdu là... Merci encore pour toute votre aide. -- It is now quite lawful for a Catholic woman to avoid pregnancy by a resort to mathematics, though she is still forbidden to resort to physics and chemistry. -- H. L. Mencken
Re: Reboot intempestifs
On 10/25/07, Vincent H. <[EMAIL PROTECTED]> wrote: > les requete ntp continue sans faire rebooter la machine. > "les requetes ntp continuent" > Bref le coup du memtest 16M est utile mais j'aimerais vraiment > comprendre quel processus faire rebooter ma machine. "processus fait" Désolé pour les fautes -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Vincent H. a écrit : > On 10/24/07, Charles Plessy <[EMAIL PROTECTED]> wrote: >> Le Tue, Oct 23, 2007 at 05:57:15PM +0200, Sylvain Sauvage a écrit : >>> D'ailleurs, si le CPU fait du speedstep/trucmuche, il peut >>> changer de tension (c'est le cas pour le Cool'n'quiet d'AMD, >>> je n'ai pas les senseurs de tension avec mon Intel). >> Hypothèse à deux francs: une vieille option oubliée du bios demande >> l'arrêt de la machine à une date précise, et cette date est oubliée à la >> fin du timeout de la commande NTP, qui prend plus de temps si la machine >> est occupée. >> >> As-tu essayé de désactiver NTP et de redémarrer ensuite ? >> > > Idée interressante. Cependant, quand je force ma machine à ne pas > rebooter (on aura tout lu!) à l'aide d'un memtest 16M je peux voir que > les requete ntp continue sans faire rebooter la machine. > > Mais il y a sans doute un rapport avec la gestion de l'énergie. Je > viens de me rappeler que j'avais eu des problèmes similaire en 2001 > avec les modem USB et les chipset VIA. Le chipset gérait mal l'usb et > la machine rebootait. > > Or il s'agit d'un chipset VIA. Carte mère Abit VH6. > Mais j'ai vérifié et j'ai déjà le dernier firmware existant pour cette > carte mère à savoir la version 7J. > > Je vais tenter l'idée de damelo de débrancher des trucs inutiles genre > lecteur de CD et vérifier que tout est bien branché. > > Au passage j'ai réinstallé munin pour voir et il fonctionne ... > > Bref le coup du memtest 16M est utile mais j'aimerais vraiment > comprendre quel processus faire rebooter ma machine. Une mise à jour > pourrait-elle être en cause? Je vais retourner voir dans les log > d'aptitude je pense... et vérifier mon hardware... > > Merci encore pour vos idées. > Penser à verifier si se n'set pas une surchauffe d'un élément (proc, chip...). Mon pb c'est réglé "tout seul" mais j'ai changer le refroidissement de mon cpu (prescott) qui chauffait a des 65° Bonne chance... -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
On 10/24/07, Charles Plessy <[EMAIL PROTECTED]> wrote: > Le Tue, Oct 23, 2007 at 05:57:15PM +0200, Sylvain Sauvage a écrit : > > D'ailleurs, si le CPU fait du speedstep/trucmuche, il peut > > changer de tension (c'est le cas pour le Cool'n'quiet d'AMD, > > je n'ai pas les senseurs de tension avec mon Intel). > > Hypothèse à deux francs: une vieille option oubliée du bios demande > l'arrêt de la machine à une date précise, et cette date est oubliée à la > fin du timeout de la commande NTP, qui prend plus de temps si la machine > est occupée. > > As-tu essayé de désactiver NTP et de redémarrer ensuite ? > Idée interressante. Cependant, quand je force ma machine à ne pas rebooter (on aura tout lu!) à l'aide d'un memtest 16M je peux voir que les requete ntp continue sans faire rebooter la machine. Mais il y a sans doute un rapport avec la gestion de l'énergie. Je viens de me rappeler que j'avais eu des problèmes similaire en 2001 avec les modem USB et les chipset VIA. Le chipset gérait mal l'usb et la machine rebootait. Or il s'agit d'un chipset VIA. Carte mère Abit VH6. Mais j'ai vérifié et j'ai déjà le dernier firmware existant pour cette carte mère à savoir la version 7J. Je vais tenter l'idée de damelo de débrancher des trucs inutiles genre lecteur de CD et vérifier que tout est bien branché. Au passage j'ai réinstallé munin pour voir et il fonctionne ... Bref le coup du memtest 16M est utile mais j'aimerais vraiment comprendre quel processus faire rebooter ma machine. Une mise à jour pourrait-elle être en cause? Je vais retourner voir dans les log d'aptitude je pense... et vérifier mon hardware... Merci encore pour vos idées. -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Le Tue, Oct 23, 2007 at 05:57:15PM +0200, Sylvain Sauvage a écrit : > D’ailleurs, si le CPU fait du speedstep/trucmuche, il peut > changer de tension (c’est le cas pour le Cool’n’quiet d’AMD, > je n’ai pas les senseurs de tension avec mon Intel). Hypothèse à deux francs: une vieille option oubliée du bios demande l'arrêt de la machine à une date précise, et cette date est oubliée à la fin du timeout de la commande NTP, qui prend plus de temps si la machine est occupée. As-tu essayé de désactiver NTP et de redémarrer ensuite ? Bonne chance. -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
Sylvain Sauvage a écrit : > Hugues LARRIVE, mardi 23 octobre 2007, 16:09:08 CEST >> […] >> De plus j'ai vu des machines planter >> (kernel panic) suite à un problème de ram mais jamais >> rebooter... (sauf sous winxp où c'est le comportement par >> défaut en cas de plantage). > ^^ > C’est pas le comportement par défaut « tout court » ;oP > Que faire? >> Essayer une autre alimentation ! ben oui, on y pense jamais à >> celle-là tant qu'elle ne fume pas, mais il arrive qu'elle ne >> crame pas d'un coup... Quel est le comportement de ce PC en >> cas de coupure ? il reste éteint ou il reboot ? Ça me semble >> quand même le premier point à vérifier en cas d'extinction / >> reboot intempestif. > > Oui, il suffit aussi parfois d’une légère faiblesse sur le > mauvais brin. La plupart du temps, ce sont les disques qui > trinquent mais pourquoi pas le CPU… > D’ailleurs, si le CPU fait du speedstep/trucmuche, il peut > changer de tension (c’est le cas pour le Cool’n’quiet d’AMD, > je n’ai pas les senseurs de tension avec mon Intel). > Bonjour. Je me suis battu avec une carte mère pour le même problème. J'ai changé celle là, puis réinstaller + tard et elle refonctionne 24/24 sans pb. (???). Peut-être le fait de tout débrancher et rebrancher peut régler le pb. Bonne chance... -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
Hugues LARRIVE, mardi 23 octobre 2007, 16:09:08 CEST >[…] > De plus j'ai vu des machines planter > (kernel panic) suite à un problème de ram mais jamais > rebooter... (sauf sous winxp où c'est le comportement par > défaut en cas de plantage). ^^ C’est pas le comportement par défaut « tout court » ;oP > >> Que faire? > >> > Essayer une autre alimentation ! ben oui, on y pense jamais à > celle-là tant qu'elle ne fume pas, mais il arrive qu'elle ne > crame pas d'un coup... Quel est le comportement de ce PC en > cas de coupure ? il reste éteint ou il reboot ? Ça me semble > quand même le premier point à vérifier en cas d'extinction / > reboot intempestif. Oui, il suffit aussi parfois d’une légère faiblesse sur le mauvais brin. La plupart du temps, ce sont les disques qui trinquent mais pourquoi pas le CPU… D’ailleurs, si le CPU fait du speedstep/trucmuche, il peut changer de tension (c’est le cas pour le Cool’n’quiet d’AMD, je n’ai pas les senseurs de tension avec mon Intel). -- Sylvain Sauvage
Re: Reboot intempestifs
On 10/23/07, Hugues LARRIVE <[EMAIL PROTECTED]> wrote: > > Ce n'est pas beaucoup, 8h30 > > > En même temps c'est beaucoup par rapport au reboot qui survient au bout > de 7 minutes, non ? C'est juste. > >> Que faire? > >> > Essayer une autre alimentation ! ben oui, on y pense jamais à celle-là > tant qu'elle ne fume pas, mais il arrive qu'elle ne crame pas d'un > coup... Quel est le comportement de ce PC en cas de coupure ? il reste > éteint ou il reboot ? Ça me semble quand même le premier point à > vérifier en cas d'extinction / reboot intempestif. > Oui l'idée est bonne, je vais m'y résigner, même si l'alimentation de ce serveur est récente (moins d'un an) et de bonne qualité (Fortron green) Cependant, j'ai pu remarquer la chose suivante: Lorsque je lance une tâche qui prend 99% du cpu (type memtester), la machine ne reboot plus! Je peux ouvrir d'autre sessions ssh et faire trop choses (lentement cependant...) Peut-etre devrais-je regarder du côté des priorités d'execution de certains processus? -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Jean-Michel OLTRA a écrit : > Bonjour, > > > Le mardi 23 octobre 2007, Vincent H. a écrit... > > > >> J'ai éxecuté memtest86+ toute la nuit: >> > > >> 8h30 de tests, 17 passes éxecutées avec succès : 0 erreur. >> > > Ce n'est pas beaucoup, 8h30 > En même temps c'est beaucoup par rapport au reboot qui survient au bout de 7 minutes, non ? à mon avis le problème de ram est une fausse piste. De plus j'ai vu des machines planter (kernel panic) suite à un problème de ram mais jamais rebooter... (sauf sous winxp où c'est le comportement par défaut en cas de plantage). > >> Que faire? >> Essayer une autre alimentation ! ben oui, on y pense jamais à celle-là tant qu'elle ne fume pas, mais il arrive qu'elle ne crame pas d'un coup... Quel est le comportement de ce PC en cas de coupure ? il reste éteint ou il reboot ? Ça me semble quand même le premier point à vérifier en cas d'extinction / reboot intempestif. signature.asc Description: OpenPGP digital signature
Re: Reboot intempestifs
Bonjour, Le mardi 23 octobre 2007, Vincent H. a écrit... > J'ai éxecuté memtest86+ toute la nuit: > 8h30 de tests, 17 passes éxecutées avec succès : 0 erreur. Ce n'est pas beaucoup, 8h30 > Que faire? Remplace ta barette, et profite en pour en mettre une de plus grande capacité. -- jm A.E.L. Sarl (R.C.S CASTRES 490843240) http://www.spidboutic.fr -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
On 10/23/07, Jean-Michel OLTRA <[EMAIL PROTECTED]> wrote: > > Bonjour, > Bonjour et merci de ta réponse, > Si tu as plusieurs barettes, essaie de les retirer une à une. J'ai déjà > eu ce problème de reboot intempestif. C'était tout bonnement une barette > mémoire défectueuse. > Alors en fait j'ai vérifié hier soir et je n'ai bien qu'une seule barrete de 128 Mo. J'ai éxecuté memtest86+ toute la nuit: 8h30 de tests, 17 passes éxecutées avec succès : 0 erreur. Que faire? J'ai regardé un peu les logs de webmin qui m'avait l'air un peu suspect, je l'ai donc purement et simplement desinstallé lui aussi car je ne m'en sers plus depuis des mois. J'ai éteint les autres machines de mon réseau local, mais cela ne change rien. Est-il possible de faire rebooter une machine en la spammant sur le net? Ai-je un moyen de vérifier cela? D'autres log peuvent-ils m'aider à comprendre ces reboots? Je ne sais plus trop où chercher là :-/ Pour rappel, au niveau du hardware, j'ai refait mon swap avec vérification des blocs défectueux (résultat: aucun bloc défectueux), testé ma ram toute la nuit (0 erreur), et j'ai fait également de la place sur / (~ 3Go). Niveau software: désinstallation de munin et de ses dépendances. désinstallation de webmin. Je suis un peu perdu là... Merci encore pour toute votre aide. -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Bonjour, Le lundi 22 octobre 2007, Vincent H. a écrit... > Je vais tester la ram en entier je pense Si tu as plusieurs barettes, essaie de les retirer une à une. J'ai déjà eu ce problème de reboot intempestif. C'était tout bonnement une barette mémoire défectueuse. -- jm A.E.L. Sarl (R.C.S CASTRES 490843240) http://www.spidboutic.fr -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
On 10/22/07, Dominique Arpin <[EMAIL PROTECTED]> wrote: > reformater la swap avec l'option -c? > > mkswap -c /dev/partition > Bon je viens de reformater ma swap [root][0]/dev$ mkswap -c /dev/hda5 Setting up swapspace version 1, size = 386551 kB no label, UUID=85ba1363-2bf4-4e6a-92a9-9f14a195cf1e Aucun block defectueux ... Je vais tester la ram en entier je pense -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
> On 10/22/07, Eric DECORNOD <[EMAIL PROTECTED]> wrote: >> Si le système a pas beaucoup de ram et que le swap est plein (oui ça >> peut >> arriver ;-) le système marche plus très très bien, mais de mes >> souvenirs, il >> en reste alors des traces dans les logs (notament kern.log). > > C'est fort possible aussi! > Au final j'ai 192 Mo de ram et il me reste 900 Mo de place sur / > > Et étrangement c'est toujours les mêmes lignes que je retrouve dans > kern.log au moment du reboot : > > Oct 22 12:51:33 thargos kernel: eth0: link up, 100Mbps, full-duplex, lpa > 0x45E1 > Oct 22 12:51:33 thargos kernel: eth1: setting full-duplex. > Oct 22 12:51:33 thargos kernel: NET: Registered protocol family 10 > Oct 22 12:51:33 thargos kernel: lo: Disabled Privacy Extensions > Oct 22 12:51:33 thargos kernel: IPv6 over IPv4 tunneling driver > Oct 22 12:51:39 thargos kernel: lp0: using parport0 (interrupt-driven). > Oct 22 12:51:39 thargos kernel: ppdev: user-space parallel port driver > Oct 22 12:51:40 thargos kernel: eth0: no IPv6 routers present > Oct 22 12:51:40 thargos kernel: eth1: no IPv6 routers present > Oct 22 13:01:37 thargos kernel: klogd 1.4.1#18, log source = /proc/kmsg > started. > > En tout cas les 2 dernières lignes avant le reboot : no IPv6 routers > present > >> >> Peut-être des badblocks sur le swap ? (mais cela risque d'être un peu >> dur à >> vérifier en moins de 7mn !) > > Comment vérifier? avec fsck? > Je crois que mon serveur l'a fait automatiquement au bout de 30 mount hier > soir. reformater la swap avec l'option -c? mkswap -c /dev/partition ou utiliser ce script: http://www.faqs.org/docs/Linux-mini/Swap-Space.html#s9 > Un autre truc bizarre, depuis que j'ai lancé des tests avec memtester > (sur 64 Mo), la machine ne reboot plus! Actuellement 15 tests passés > sans erreur (sur 1/3 de la ram) > > -- > Vincent H > "Early Optimization is the root of all evil" - Donald Knuth > > -- Dominique Arpin, administrateur réseau A+,Linux+,Server+,MCP Espace Courbe inc. http://www.espacecourbe.com/ 642 de Courcelle, bureau 303, Montréal (Québec), Canada H4C 3C5 tél.: (514) 933-9861 téléc.: (514) 933-9546 -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot intempestifs
On 10/22/07, Eric DECORNOD <[EMAIL PROTECTED]> wrote: > Si le système a pas beaucoup de ram et que le swap est plein (oui ça peut > arriver ;-) le système marche plus très très bien, mais de mes souvenirs, il > en reste alors des traces dans les logs (notament kern.log). C'est fort possible aussi! Au final j'ai 192 Mo de ram et il me reste 900 Mo de place sur / Et étrangement c'est toujours les mêmes lignes que je retrouve dans kern.log au moment du reboot : Oct 22 12:51:33 thargos kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Oct 22 12:51:33 thargos kernel: eth1: setting full-duplex. Oct 22 12:51:33 thargos kernel: NET: Registered protocol family 10 Oct 22 12:51:33 thargos kernel: lo: Disabled Privacy Extensions Oct 22 12:51:33 thargos kernel: IPv6 over IPv4 tunneling driver Oct 22 12:51:39 thargos kernel: lp0: using parport0 (interrupt-driven). Oct 22 12:51:39 thargos kernel: ppdev: user-space parallel port driver Oct 22 12:51:40 thargos kernel: eth0: no IPv6 routers present Oct 22 12:51:40 thargos kernel: eth1: no IPv6 routers present Oct 22 13:01:37 thargos kernel: klogd 1.4.1#18, log source = /proc/kmsg started. En tout cas les 2 dernières lignes avant le reboot : no IPv6 routers present > > Peut-être des badblocks sur le swap ? (mais cela risque d'être un peu dur à > vérifier en moins de 7mn !) Comment vérifier? avec fsck? Je crois que mon serveur l'a fait automatiquement au bout de 30 mount hier soir. Un autre truc bizarre, depuis que j'ai lancé des tests avec memtester (sur 64 Mo), la machine ne reboot plus! Actuellement 15 tests passés sans erreur (sur 1/3 de la ram) -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Le lundi 22 octobre 2007, Vincent H. a écrit : > On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: > Merci pour les infos :) > Je vais voir du côté de memtester. Sinon je testerais tout ça ce soir. > Je crois qu'il n'y a qu'une barrette de ram sur cette machine... 128Mo... > :-/ Merci encore. Si le système a pas beaucoup de ram et que le swap est plein (oui ça peut arriver ;-) le système marche plus très très bien, mais de mes souvenirs, il en reste alors des traces dans les logs (notament kern.log). Peut-être des badblocks sur le swap ? (mais cela risque d'être un peu dur à vérifier en moins de 7mn !) Cordialement, -- Eric DÉCORNOD
Re: Reboot intempestifs
On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: > Si tu n'as pas la main sur la console (KVM réseau, console série via > réseau...) ça va être dur. > > Sinon, tu peux essayer en live memtester, en lui faisant tester une bonne > partie de ta mémoire (pas toute, sinon ça va tout bloquer). > Si le serveur plante systématiquement en lançant un test mémoire > Par contre, tu ne sauras pas quelle barrette, là il faudra être sur place et > tester chaque barrette toute seule. > Merci pour les infos :) Je vais voir du côté de memtester. Sinon je testerais tout ça ce soir. Je crois qu'il n'y a qu'une barrette de ram sur cette machine... 128Mo... :-/ Merci encore. -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Le Monday 22 October 2007 11:54:40 Vincent H., vous avez écrit : > > On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: > > > Un petit coup de memtest86++ permettrait d'en savoir plus. > > Est-il possible de booter sur memtest86, faire une serie de test (qui > log le tout quelque part) et ensuite rebooter automatiquement le > serveur pour me permettre d'avoir à nouveau la main et finalement > étudier les logs? > > J'ai installé memtest86, il s'est à priori rajouté tout seul dans grub > (j'ai pas eu le temps de lire le fichier menu.lst en entier mais j'ai > pu trouver un memtest86 dedans) Si tu n'as pas la main sur la console (KVM réseau, console série via réseau...) ça va être dur. Sinon, tu peux essayer en live memtester, en lui faisant tester une bonne partie de ta mémoire (pas toute, sinon ça va tout bloquer). Si le serveur plante systématiquement en lançant un test mémoire Par contre, tu ne sauras pas quelle barrette, là il faudra être sur place et tester chaque barrette toute seule. signature.asc Description: This is a digitally signed message part.
Re: Reboot intempestifs
> On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: > > Un petit coup de memtest86++ permettrait d'en savoir plus. > Est-il possible de booter sur memtest86, faire une serie de test (qui log le tout quelque part) et ensuite rebooter automatiquement le serveur pour me permettre d'avoir à nouveau la main et finalement étudier les logs? J'ai installé memtest86, il s'est à priori rajouté tout seul dans grub (j'ai pas eu le temps de lire le fichier menu.lst en entier mais j'ai pu trouver un memtest86 dedans) -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
On 10/22/07, Gilles Mocellin <[EMAIL PROTECTED]> wrote: > Je pense que c'est justement après le reboot. > exact. > Donc, le syslog n'a rien écrit avant le redémarrage, c'est un beau plantage. > Je soupçonnerais d'emblée la mémoire. > Un petit coup de memtest86++ permettrait d'en savoir plus. ok merci pour ta réponse également :) je vais tenter ça Sinon le contenu de /etc/crontab est le suivant: # /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 ** * * rootcd / && run-parts --report /etc/cron.hourly 25 6* * * roottest -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6* * 7 roottest -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 61 * * roottest -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) # mais bon le fichier date du 20 12 2006 -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Merci Daniel pour ta réponse rapide. On 10/22/07, Daniel Caillibaud <[EMAIL PROTECTED]> wrote: > Ou alors une dépendance installée par munin qui resterait. > Tu as installé munin avec aptitude ? > Si oui, regarde le log Dans le log j'ai trouvé ceci d'interressant : [INSTALLÉ, DÉPENDANCES] libart-2.0-2 [INSTALLÉ, DÉPENDANCES] libdate-manip-perl [INSTALLÉ, DÉPENDANCES] libhtml-template-perl [INSTALLÉ, DÉPENDANCES] libio-multiplex-perl [INSTALLÉ, DÉPENDANCES] libnet-cidr-perl [INSTALLÉ, DÉPENDANCES] libnet-server-perl [INSTALLÉ, DÉPENDANCES] libnet-snmp-perl [INSTALLÉ, DÉPENDANCES] librrd2 [INSTALLÉ, DÉPENDANCES] librrds-perl [INSTALLÉ, DÉPENDANCES] rrdtool [INSTALLÉ, DÉPENDANCES] ttf-dejavu [INSTALLÉ] munin [INSTALLÉ] munin-node et plus bas les memes dépendances retirées sauf ttf-dejavu que je viens de retirer avec un aptitude remove (meme si ce n'est qu'une police apparement). > > Tu peux aussi regarder > ls -tl /var/cache/apt/archives/|head > pour regarder les dernier deb téléchargés. De ce côté ça a l'air ok puisque je ne retrouve pas munin ni aucun paquets des dépendances. De plus le fichier le plus récent date du 13/10 et j'ai installé munin le 19/10. > > 10 min pour une synchro ntp, c'est bizarre... > Oui c'est peut-être un peu rapide. Il faudrait que je regarde ma config mais ça tourne comme ça depuis un bail a priori, j'ai configuré ça il y a des mois. > > Pourquoi ton syslog redémarre toutes les 7 min ? > Parce que mon serveur est resté allumé 7 minutes :) Ce qui ne facilite pas ma tâche à distance > > Dernière info sur munin. Après un updatedb, locate munin me donne ça: > > > > [vincent][0]~$ locate munin > > /var/cache/apt/archives/munin_1.2.5-1_all.deb > > /var/cache/apt/archives/munin-node_1.2.5-1_all.deb > > [vincent][0]~$ > > > > Donc je pense que de ce côté c'est clean (?) > > Oui. ok :) j'ai également coupé apache2 et plusieurs services ouvert sur le net mais les reboot persistent... Il reste de la place sur mon / (même si il est bien plein...) Je continue mes recherches... -- Vincent H "Early Optimization is the root of all evil" - Donald Knuth
Re: Reboot intempestifs
Le Monday 22 October 2007 11:18:09 Daniel Caillibaud, vous avez écrit : > Vincent H. a écrit : [...] > > Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, stratum > > 2 Oct 22 10:13:00 thargos ntpd[4157]: kernel time sync enabled 0001 Oct > > 22 10:17:01 thargos /USR/SBIN/CRON[4297]: (root) CMD ( cd / && > > run-parts --report /etc/cron.hourly) > > Oct 22 10:19:05 thargos syslogd 1.4.1#18: restart. > > Pourquoi ton syslog redémarre toutes les 7 min ? Je pense que c'est justement après le reboot. Donc, le syslog n'a rien écrit avant le redémarrage, c'est un beau plantage. Je soupçonnerais d'emblée la mémoire. Un petit coup de memtest86++ permettrait d'en savoir plus. signature.asc Description: This is a digitally signed message part.
Re: Reboot intempestifs
Vincent H. a écrit : Cependant, depuis ces operations, mon serveur reboot sans arrêt... Peut-être que munin n'était pas la cause et que les reboot sont arrivés en même temps par pure coincidence alors? Ou alors une dépendance installée par munin qui resterait. Tu as installé munin avec aptitude ? Si oui, regarde le log Tu peux aussi regarder ls -tl /var/cache/apt/archives/|head pour regarder les dernier deb téléchargés. Néanmoins voici mon syslog de l'instant, juste avant un reboot: Oct 22 09:49:13 thargos ntpd[2774]: synchronized to 88.191.12.184, stratum 2 Oct 22 09:49:13 thargos ntpd[2774]: kernel time sync enabled 0001 Oct 22 09:58:47 thargos ntpd[2774]: synchronized to 88.191.14.223, stratum 2 Oct 22 10:12:38 thargos syslogd 1.4.1#18: restart. 10 min pour une synchro ntp, c'est bizarre... un autre Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, stratum 2 Oct 22 10:13:00 thargos ntpd[4157]: kernel time sync enabled 0001 Oct 22 10:17:01 thargos /USR/SBIN/CRON[4297]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Oct 22 10:19:05 thargos syslogd 1.4.1#18: restart. Pourquoi ton syslog redémarre toutes les 7 min ? Clairement, je manque d'info Je ne sais pas trop où chercher ce qui fait rebooter mon serveur. Mais c'est souvent suite à un /USR/SBIN/CRON Donc regarde /etc/crontab et /etc/cron*/* Or j'ai regardé dans le crontab du root et je n'ai rien de planifié qui fasse rebooter la machine toutes les 5 minutes. D'ailleurs je n'ai pas touché au crontab du root depuis des mois. Quelqu'un aurait-il une piste s'il vous plait? Dernière info sur munin. Après un updatedb, locate munin me donne ça: [vincent][0]~$ locate munin /var/cache/apt/archives/munin_1.2.5-1_all.deb /var/cache/apt/archives/munin-node_1.2.5-1_all.deb [vincent][0]~$ Donc je pense que de ce côté c'est clean (?) Oui. -- Daniel -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reboot intempestifs
Bonjour la liste, Suite à une installation Vendredi de munin et munin-node sur mon serveur, ce dernier est devenu extremement instable : - Connexion ssh fermées - plus de passerelle internet, bref le neant. je reboot je reprends la main et je désinstalle munin en me disant que le problème vient surement de ce nouveau logiciel. La désinstallation se passe moyennement bien car suite à un aptitude remove munin munin-node j'avais encore des executions par /usr/sbin/cron dans mes log (syslog) je finis de tout virer à coup de dpkg --purge et de locate munin Cependant, depuis ces operations, mon serveur reboot sans arrêt... Peut-être que munin n'était pas la cause et que les reboot sont arrivés en même temps par pure coincidence alors? Néanmoins voici mon syslog de l'instant, juste avant un reboot: Oct 22 09:49:13 thargos ntpd[2774]: synchronized to 88.191.12.184, stratum 2 Oct 22 09:49:13 thargos ntpd[2774]: kernel time sync enabled 0001 Oct 22 09:58:47 thargos ntpd[2774]: synchronized to 88.191.14.223, stratum 2 Oct 22 10:12:38 thargos syslogd 1.4.1#18: restart. un autre Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, stratum 2 Oct 22 10:13:00 thargos ntpd[4157]: kernel time sync enabled 0001 Oct 22 10:17:01 thargos /USR/SBIN/CRON[4297]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Oct 22 10:19:05 thargos syslogd 1.4.1#18: restart. Clairement, je manque d'info Je ne sais pas trop où chercher ce qui fait rebooter mon serveur. Mais c'est souvent suite à un /USR/SBIN/CRON Or j'ai regardé dans le crontab du root et je n'ai rien de planifié qui fasse rebooter la machine toutes les 5 minutes. D'ailleurs je n'ai pas touché au crontab du root depuis des mois. Quelqu'un aurait-il une piste s'il vous plait? Dernière info sur munin. Après un updatedb, locate munin me donne ça: [vincent][0]~$ locate munin /var/cache/apt/archives/munin_1.2.5-1_all.deb /var/cache/apt/archives/munin-node_1.2.5-1_all.deb [vincent][0]~$ Donc je pense que de ce côté c'est clean (?) Merci d'avance! -- Vincent H
Reboot intempestifs
Je viens d'installer une bécane en Sarge, que j'ai ensuite passé en 2.6.6 (kernel Debian standard). Et depuis qu'elle est en 2.6, elle subit des reboot intempestifs. Seul indicce pour le moment, ces deux lignes qui apparaissent systématiquement dans user.log, juste avant le reboot : jun 16 20:39:30 khayyam gconfd (eliope-8498): Le serveur GConf n'est pas en cours d'utilisation, arrêt. jun 16 20:39:30 khayyam gconfd (eliope-8498): Sortie Jun 16 20:39:50 khayyam shutdown[10447]: shutting down for system reboot Dans user.log, rien dans les deux minutes précédentes. Est-ce que GConf peut foutre le boxon, et si oui, comment dignostiquer ce qui ne va pas ? (pas vu de script dans init.d, où j'aurais pu le [ls]tracer, par exemple) Intempestivement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: reboot intempestifs (suite)
Le vendredi 06 février 2004, Vincent Tuybens a écrit... bonjour, > comme je ne peux plus du tout redemmarer Ça rebouterait sur un cd rescue ? -- jm
reboot intempestifs (suite)
comme je ne peux plus du tout redemmarer J'ai donc essayer de trouver un probleme Hard (barette mem, graveur, alim., ) sans succes. Il se trouve que ma machine marche bien avec un DD Windowsé ! J'en conclus que ca vient donc de mon disque. Alors est-ce un probleme Hard ou Soft, that the question ? Comment faire maintenant pour "checker" l'integrite de mon disque sachant que je ne peux meme plus demarrer avec ce dernier ? Si ce n'est pas un probleme Hard, savez vous la cause d'un tel disfonctionnement (reboot lors de la sequence de boot aleatoirement, reboot tout seul en cours d'utilisation) ? La derniere manip effectue sur ma Woody avant que ca marche plus est un essaie de compile des pilotes son ALSA et l'install de mon graveur CD Samsung via emulation SCSI. Merci.
