Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à
intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et
les barettes ont été testées pendant 48h avec memtest86.
La machine ne se gèle pas complètement, elle continue à répondre à des
pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondre à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
Et aucune trace de rien dans les logs.
Aideeeeeez moi !!!!!
Le sshd répond ?
-- Sebastien Bricout
De deux douleurs simultanées, la plus forte obscurcit l'autre. -+- Hippocrate (Médecin grec) -+-
On 18 Sep 2003 11:11:03 GMT, Zouplaz <pouet@pouet.com> wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à
intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et
les barettes ont été testées pendant 48h avec memtest86.
La machine ne se gèle pas complètement, elle continue à répondre à des
pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
Et aucune trace de rien dans les logs.
Aideeeeeez moi !!!!!
Le sshd répond ?
--
Sebastien Bricout
De deux douleurs simultanées, la plus forte obscurcit l'autre.
-+- Hippocrate (Médecin grec) -+-
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondre à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
Et aucune trace de rien dans les logs.
Aideeeeeez moi !!!!!
Le sshd répond ?
-- Sebastien Bricout
De deux douleurs simultanées, la plus forte obscurcit l'autre. -+- Hippocrate (Médecin grec) -+-
Zouplaz
Sebastien Bricout - :
Le sshd répond ?
Non, rien de rien... Plus de console, plus de services.
Sebastien Bricout - sbricout@tiscali.fr :
Le sshd répond ?
Non, rien de rien... Plus de console, plus de services.
Non, rien de rien... Plus de console, plus de services.
GERBIER Eric
Zouplaz wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilé e et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondr e à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une consol e il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'es t passe dernierement) sur la machine
-- Eric Gerbier cnrm/cti
Zouplaz wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à
intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilé e et
les barettes ont été testées pendant 48h avec memtest86.
La machine ne se gèle pas complètement, elle continue à répondr e à des
pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ?
(desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca
(voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une consol e
il suffit de rajouter la ligne suivante dans /etc/syslog.conf :
*.* /dev/tty9
de relancer syslog : killall -1 syslogd
et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'es t passe
dernierement) sur la machine
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilé e et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondr e à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une consol e il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'es t passe dernierement) sur la machine
-- Eric Gerbier cnrm/cti
J. Mayer
On Thu, 18 Sep 2003 17:16:23 +0200, GERBIER Eric wrote:
Zouplaz wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondre à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une console il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'est passe dernierement) sur la machine
Le scheduler a du planter, donc tout ce qui est en mode user est freezé, mais au moins le thread kernel principal tourne, ce qui suffit pour répondre au ping. Je n'ai pas de solution miracle, mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19 ont des bugs qui peuvent mener une machine au freeze, mais généralement ce sont des freeze temporaires... Si ca n'arrange rien, je n'ai rien de mieux à proposer, mais c'est surement un composant qui flanche et freeze une partie du kernel, ou qui envoie des rafales d'interruptions qui font que le kernel n'a plus le temps de passer la main aux processes (déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines interruptions et provoque le même résultat...
On Thu, 18 Sep 2003 17:16:23 +0200, GERBIER Eric wrote:
Zouplaz wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à
intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et
les barettes ont été testées pendant 48h avec memtest86.
La machine ne se gèle pas complètement, elle continue à répondre à des
pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ?
(desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca
(voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une console
il suffit de rajouter la ligne suivante dans /etc/syslog.conf :
*.* /dev/tty9
de relancer syslog : killall -1 syslogd
et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'est passe
dernierement) sur la machine
Le scheduler a du planter, donc tout ce qui est en mode user est
freezé, mais au moins le thread kernel principal tourne, ce qui
suffit pour répondre au ping. Je n'ai pas de solution miracle,
mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19
ont des bugs qui peuvent mener une machine au freeze, mais
généralement ce sont des freeze temporaires...
Si ca n'arrange rien, je n'ai rien de mieux à proposer,
mais c'est surement un composant qui flanche et freeze une partie
du kernel, ou qui envoie des rafales d'interruptions qui font
que le kernel n'a plus le temps de passer la main aux processes
(déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines
interruptions et provoque le même résultat...
On Thu, 18 Sep 2003 17:16:23 +0200, GERBIER Eric wrote:
Zouplaz wrote:
Bonjour, j'avais déjà mentionné un problème avec un serveur qui crash à intervalle régulier (au bout de 7 à 8 jours).
La machine n'est plus toute jeune mais avec disque neuf, bien ventilée et les barettes ont été testées pendant 48h avec memtest86. La machine ne se gèle pas complètement, elle continue à répondre à des pings preuve que le kernel (2.4.18) est toujours fonctionnel.
Par contre, TOUT le reste est planté.
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une console il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'est passe dernierement) sur la machine
Le scheduler a du planter, donc tout ce qui est en mode user est freezé, mais au moins le thread kernel principal tourne, ce qui suffit pour répondre au ping. Je n'ai pas de solution miracle, mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19 ont des bugs qui peuvent mener une machine au freeze, mais généralement ce sont des freeze temporaires... Si ca n'arrange rien, je n'ai rien de mieux à proposer, mais c'est surement un composant qui flanche et freeze une partie du kernel, ou qui envoie des rafales d'interruptions qui font que le kernel n'a plus le temps de passer la main aux processes (déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines interruptions et provoque le même résultat...
nicolas
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
nicolas patrois : pts noir asocial -- PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur... P : ...Et les pacifistes !
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
nicolas patrois : pts noir asocial
--
PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur...
P : ...Et les pacifistes !
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
nicolas patrois : pts noir asocial -- PEACE
M : La guerre, ça amène la mort, les épidémie, la vermine... la souffrance, la destruction, la peur... P : ...Et les pacifistes !
Zouplaz
GERBIER Eric - :
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une console il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'est passe dernierement) sur la machine
Non, l'option n'est pas compilé dans le kernel d'origine (RH7.3).
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
GERBIER Eric - eric.gerbier@meteo.fr :
est-ce que les touches de "magic SysRq" marchent encore ?
(desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca
(voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une
console il suffit de rajouter la ligne suivante dans /etc/syslog.conf
: *.*
/dev/tty9
de relancer syslog : killall -1 syslogd
et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui
s'est passe dernierement) sur la machine
Non, l'option n'est pas compilé dans le kernel d'origine (RH7.3).
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car
la bécane se trouve à quelques kilomètres de mon poste de travail...
est-ce que les touches de "magic SysRq" marchent encore ? (desole je ne connais pas la traduction francaise)
attention, il faut que le noyau soit compile pour ca (voir /usr/src/linux/Documentation/sysrq.txt)
autre piste pour savoir ce qui se passe, rediriger syslog vers une console il suffit de rajouter la ligne suivante dans /etc/syslog.conf : *.* /dev/tty9
de relancer syslog : killall -1 syslogd et alt+ctrl+f9 permet de savoir tout ce qui se passe (ou tout ce qui s'est passe dernierement) sur la machine
Non, l'option n'est pas compilé dans le kernel d'origine (RH7.3).
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
Zouplaz
J. Mayer - :
Le scheduler a du planter, donc tout ce qui est en mode user est freezé, mais au moins le thread kernel principal tourne, ce qui suffit pour répondre au ping. Je n'ai pas de solution miracle, mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19 ont des bugs qui peuvent mener une machine au freeze, mais généralement ce sont des freeze temporaires... Si ca n'arrange rien, je n'ai rien de mieux à proposer, mais c'est surement un composant qui flanche et freeze une partie du kernel, ou qui envoie des rafales d'interruptions qui font que le kernel n'a plus le temps de passer la main aux processes (déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines interruptions et provoque le même résultat...
J'hésitais, mais je pense vraiment que je vais profiter du week-end pour upgrader vers un 2.4.22 (qui tourne bien chez moi, mais en discontinu, seulement 12 heures / jours).
J. Mayer - l_indien_no_more_spams@magic.fr :
Le scheduler a du planter, donc tout ce qui est en mode user est
freezé, mais au moins le thread kernel principal tourne, ce qui
suffit pour répondre au ping. Je n'ai pas de solution miracle,
mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19
ont des bugs qui peuvent mener une machine au freeze, mais
généralement ce sont des freeze temporaires...
Si ca n'arrange rien, je n'ai rien de mieux à proposer,
mais c'est surement un composant qui flanche et freeze une partie
du kernel, ou qui envoie des rafales d'interruptions qui font
que le kernel n'a plus le temps de passer la main aux processes
(déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines
interruptions et provoque le même résultat...
J'hésitais, mais je pense vraiment que je vais profiter du week-end pour
upgrader vers un 2.4.22 (qui tourne bien chez moi, mais en discontinu,
seulement 12 heures / jours).
Le scheduler a du planter, donc tout ce qui est en mode user est freezé, mais au moins le thread kernel principal tourne, ce qui suffit pour répondre au ping. Je n'ai pas de solution miracle, mais dans un premier temps, upgrade ton kernel: les 2.4.18 & 2.4.19 ont des bugs qui peuvent mener une machine au freeze, mais généralement ce sont des freeze temporaires... Si ca n'arrange rien, je n'ai rien de mieux à proposer, mais c'est surement un composant qui flanche et freeze une partie du kernel, ou qui envoie des rafales d'interruptions qui font que le kernel n'a plus le temps de passer la main aux processes (déjà vu...) ou un driver buggé qui oublie de "ACKer" certaines interruptions et provoque le même résultat...
J'hésitais, mais je pense vraiment que je vais profiter du week-end pour upgrader vers un 2.4.22 (qui tourne bien chez moi, mais en discontinu, seulement 12 heures / jours).
Zouplaz
nicolas - :
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
Ca m'est déjà arrivé et ça c'est avéré utile.
Dans le cas présent ça serait plutôt acheter un Dell poweredge mais ça douille un peu (ptite société, on en a déjà un "gros" (pour nous) alors bon... ahem on fait s'qu'on peut !! mais on y viendra surement )
nicolas - nicolas.patrois@online.fr :
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
Ca m'est déjà arrivé et ça c'est avéré utile.
Dans le cas présent ça serait plutôt acheter un Dell poweredge mais ça
douille un peu (ptite société, on en a déjà un "gros" (pour nous) alors
bon... ahem on fait s'qu'on peut !! mais on y viendra surement )
On Thu, 18 Sep 2003 13:11:03 +0200, Zouplaz wrote:
Par contre, TOUT le reste est planté.
Change de carte mère ?
Ca m'est déjà arrivé et ça c'est avéré utile.
Dans le cas présent ça serait plutôt acheter un Dell poweredge mais ça douille un peu (ptite société, on en a déjà un "gros" (pour nous) alors bon... ahem on fait s'qu'on peut !! mais on y viendra surement )
J. Mayer
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
Redirige les logs en IP, ça marche nickel... Tu les envoie sur un port non standard, ce qui te permet de les filtrer et de les distinguer puis de les admirer à distance sans avoir besoin de te connecter à ta machine...
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car
la bécane se trouve à quelques kilomètres de mon poste de travail...
Redirige les logs en IP, ça marche nickel...
Tu les envoie sur un port non standard, ce qui te permet de les
filtrer et de les distinguer puis de les admirer à distance
sans avoir besoin de te connecter à ta machine...
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
Redirige les logs en IP, ça marche nickel... Tu les envoie sur un port non standard, ce qui te permet de les filtrer et de les distinguer puis de les admirer à distance sans avoir besoin de te connecter à ta machine...
Zouplaz
J. Mayer - :
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
Redirige les logs en IP, ça marche nickel... Tu les envoie sur un port non standard, ce qui te permet de les filtrer et de les distinguer puis de les admirer à distance sans avoir besoin de te connecter à ta machine...
Heu, quel est le principe ? Je suppose qu'un man syslogd va m'aider mais bon...
J'ai deux serveurs linux, un de prod (loin) et un de dev (a côté)...
Ca signifie que celui de prod de fait qu'envoyer des données donc pas de failles de sécurité (sur le serv de dev c'est pas un gros soucis) ?
J. Mayer - l_indien_no_more_spams@magic.fr :
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier
log car la bécane se trouve à quelques kilomètres de mon poste de
travail...
Redirige les logs en IP, ça marche nickel...
Tu les envoie sur un port non standard, ce qui te permet de les
filtrer et de les distinguer puis de les admirer à distance
sans avoir besoin de te connecter à ta machine...
Heu, quel est le principe ? Je suppose qu'un man syslogd va m'aider mais
bon...
J'ai deux serveurs linux, un de prod (loin) et un de dev (a côté)...
Ca signifie que celui de prod de fait qu'envoyer des données donc pas de
failles de sécurité (sur le serv de dev c'est pas un gros soucis) ?
On Fri, 19 Sep 2003 19:35:04 +0000, Zouplaz wrote:
J'aimerais plutôt rediriger ce qui sort en console vers un fichier log car la bécane se trouve à quelques kilomètres de mon poste de travail...
Redirige les logs en IP, ça marche nickel... Tu les envoie sur un port non standard, ce qui te permet de les filtrer et de les distinguer puis de les admirer à distance sans avoir besoin de te connecter à ta machine...
Heu, quel est le principe ? Je suppose qu'un man syslogd va m'aider mais bon...
J'ai deux serveurs linux, un de prod (loin) et un de dev (a côté)...
Ca signifie que celui de prod de fait qu'envoyer des données donc pas de failles de sécurité (sur le serv de dev c'est pas un gros soucis) ?
