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 (?)
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 (?)
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 (?)
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.
10 min pour une synchro ntp, c'est bizarre...
Pourquoi ton syslog redémarre toutes les 7 min ?
> 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.
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.
10 min pour une synchro ntp, c'est bizarre...
Pourquoi ton syslog redémarre toutes les 7 min ?
> 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.
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.
10 min pour une synchro ntp, c'est bizarre...
Pourquoi ton syslog redémarre toutes les 7 min ?
> 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.
Vincent H. a écrit :
> Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, strat um
> 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 ?
Vincent H. a écrit :
> Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, strat um
> 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 ?
Vincent H. a écrit :
> Oct 22 10:13:00 thargos ntpd[4157]: synchronized to 88.191.19.23, strat um
> 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 pl antage.
Je soupçonnerais d'emblée la mémoire.
Un petit coup de memtest86++ permettrait d'en savoir plus.
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 pl antage.
Je soupçonnerais d'emblée la mémoire.
Un petit coup de memtest86++ permettrait d'en savoir plus.
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 pl antage.
Je soupçonnerais d'emblée la mémoire.
Un petit coup de memtest86++ permettrait d'en savoir plus.
> On 10/22/07, Gilles Mocellin wrote:
> Un petit coup de memtest86++ permettrait d'en savoir plus.
> On 10/22/07, Gilles Mocellin <gilles.mocellin@free.fr> wrote:
> Un petit coup de memtest86++ permettrait d'en savoir plus.
> On 10/22/07, Gilles Mocellin wrote:
> Un petit coup de memtest86++ permettrait d'en savoir plus.
> On 10/22/07, Gilles Mocellin 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 g rub
(j'ai pas eu le temps de lire le fichier menu.lst en entier mais j'ai
pu trouver un memtest86 dedans)
> On 10/22/07, Gilles Mocellin <gilles.mocellin@free.fr> 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 g rub
(j'ai pas eu le temps de lire le fichier menu.lst en entier mais j'ai
pu trouver un memtest86 dedans)
> On 10/22/07, Gilles Mocellin 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 g rub
(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 p lace et
tester chaque barrette toute seule.
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 p lace et
tester chaque barrette toute seule.
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 p lace et
tester chaque barrette toute seule.
On 10/22/07, Gilles Mocellin wrote:
Merci pour les infos :)
Je vais voir du côté de memtester. Sinon je testerais tout ça ce so ir.
Je crois qu'il n'y a qu'une barrette de ram sur cette machine... 128Mo...
:-/ Merci encore.
On 10/22/07, Gilles Mocellin <gilles.mocellin@free.fr> wrote:
Merci pour les infos :)
Je vais voir du côté de memtester. Sinon je testerais tout ça ce so ir.
Je crois qu'il n'y a qu'une barrette de ram sur cette machine... 128Mo...
:-/ Merci encore.
On 10/22/07, Gilles Mocellin wrote:
Merci pour les infos :)
Je vais voir du côté de memtester. Sinon je testerais tout ça ce so ir.
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 souv enirs, 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 !)
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 souv enirs, 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 !)
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 souv enirs, 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 !)
> On 10/22/07, Eric DECORNOD 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
> On 10/22/07, Eric DECORNOD <eric@decornod.com> 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
> On 10/22/07, Eric DECORNOD 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