J'ai un souci avec un serveur tournant sous debian/testing. Il
plante assez aléatoirement (au sens tout est mort, plus d'accès à la
console).
J'ai tout d'abord mis en cause le matériel, la mémoire, enfin tout
ce qui est susceptible de tomber en panne. J'ai fait tourner memtest
plusieurs jours (en bootant sous memtest), rien à signaler. Les
disques SCSI sont impécables. La machine peut ronronner plusieurs
semaines sans aucun problème avec des charges montant à 5 ou 6 en
pointe. Et de temps en temps, un plantage sévère et rien dans les
logs.
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se
produit toujours à xxh17 (toutes les 17 minutes de chaque heure),
heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script
qui vérifie si la connexion ADSL est toujours active et qui reboote
le cas échéant le modem.
if [ $TEST_PING -eq 0 ]; then
expect << EOS
spawn telnet einstein.systella.fr
expect "login: "
send -- "superuser\r"
expect "password: "
send -- "5200admin\r"
expect "xsh>"
send -- "do reboot\r"
sleep 5
exit
EOS
fi
exit 0
Je ne vois pas pourquoi ce script ferait planter sévèrement mon
serveur. Sur google, j'ai lu un certain nombre de personnes qui
avaient un problème similaire, mais sans jamais donner de solution.
Alors si l'un d'entre vous avait une idée... Merci d'avance de me la
communiquer ;-)
Pour information, la configuration matérielle est :
- carte mère D5Cub/512 avec un P166 non MMX et 128 Mo de mémoire ;
- une carte graphique Matrox Millenium 2 4 Mo ;
- deux cartes réseau Ethernet Digital Tulip ;
- une carte raid SCSI gdth avec plusieurs disques SCSI ;
- un lecteur de CDROM en IDE ;
- floppies 3"1/2 et 5"1/4.
Merci de votre attention,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se produit toujours à xxh17 (toutes les 17 minutes de chaque heure), heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script qui vérifie si la connexion ADSL est toujours active et qui reboote le cas échéant le modem.
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est pas du linux?). Genre un halt au lieu d'un reboot.
-- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 23-12-2004, JKB <knatschke@chezmoi.com> a écrit :
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se
produit toujours à xxh17 (toutes les 17 minutes de chaque heure),
heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script
qui vérifie si la connexion ADSL est toujours active et qui reboote
le cas échéant le modem.
Autre truc: chez moi ping n'affiche pas packets received, mais:
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
Donc:
kevin@zipslack:~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/packets received/
{printf("%dn", $4);}'
kevin@zipslack:~/tmp$ <-- Rien !!
Et le script s'activera toutes les heures et 17 minutes.
Mais
kevin@zipslack:~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/received/
{printf("%dn", $4);}'
4 <-- C'est plus normal
kevin@zipslack:~/tmp$
A tester, amha.
if [ $TEST_PING -eq 0 ]; then
expect << EOS
spawn telnet einstein.systella.fr
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est
pas du linux?). Genre un halt au lieu d'un reboot.
--
Kevin
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se produit toujours à xxh17 (toutes les 17 minutes de chaque heure), heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script qui vérifie si la connexion ADSL est toujours active et qui reboote le cas échéant le modem.
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est pas du linux?). Genre un halt au lieu d'un reboot.
-- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Kevin Denis écrivait dans fr.comp.os.linux.moderated :
Le 23-12-2004, JKB a écrit :
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se produit toujours à xxh17 (toutes les 17 minutes de chaque heure), heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script qui vérifie si la connexion ADSL est toujours active et qui reboote le cas échéant le modem.
Question bete: Et si tu desactives ce script?
Je ne sais pas. Le truc n'est pas reproductible. Pour information, j'ai fait tourner toute la nuit ce script en boucle dans un run-parts sans souci !
Autre truc: chez moi ping n'affiche pas packets received, mais: 4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rayleigh:[~] > ping -c 4 www.nerim.fr PING www0.nerim.net (62.4.16.81): 56 data bytes 64 bytes from 62.4.16.81: icmp_seq=0 ttl` time1.3 ms 64 bytes from 62.4.16.81: icmp_seq=1 ttl` time%.1 ms 64 bytes from 62.4.16.81: icmp_seq=2 ttl` time$.5 ms 64 bytes from 62.4.16.81: icmp_seq=3 ttl` time#.9 ms
Donc: :~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/packets received/ {printf("%dn", $4);}' :~/tmp$ <-- Rien !! Et le script s'activera toutes les heures et 17 minutes.
Mais :~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/received/ {printf("%dn", $4);}' 4 <-- C'est plus normal :~/tmp$ A tester, amha.
if [ $TEST_PING -eq 0 ]; then expect << EOS spawn telnet einstein.systella.fr
Un ssh serait plus elegant, non?
Non, il ne peut être attaqué que par telnet et le mot de passe est figé. Comme il est dans la doc et utilisable que sur l'interface LAN, je ne vois pas bien la peine de le cacher.
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est pas du linux?). Genre un halt au lieu d'un reboot.
Non, c'est un routeur. Et cela plante _avant_ ou _au_ lancement du script. En fait, j'ai écrit ce script parce que de temps en temps, une trame bizarre arrive du WAN et fait planter sauvagement le routeur...
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Kevin Denis écrivait dans fr.comp.os.linux.moderated :
Le 23-12-2004, JKB <knatschke@chezmoi.com> a écrit :
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se
produit toujours à xxh17 (toutes les 17 minutes de chaque heure),
heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script
qui vérifie si la connexion ADSL est toujours active et qui reboote
le cas échéant le modem.
Question bete: Et si tu desactives ce script?
Je ne sais pas. Le truc n'est pas reproductible. Pour information,
j'ai fait tourner toute la nuit ce script en boucle dans un
run-parts sans souci !
Autre truc: chez moi ping n'affiche pas packets received, mais:
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rayleigh:[~] > ping -c 4 www.nerim.fr
PING www0.nerim.net (62.4.16.81): 56 data bytes
64 bytes from 62.4.16.81: icmp_seq=0 ttl` time1.3 ms
64 bytes from 62.4.16.81: icmp_seq=1 ttl` time%.1 ms
64 bytes from 62.4.16.81: icmp_seq=2 ttl` time$.5 ms
64 bytes from 62.4.16.81: icmp_seq=3 ttl` time#.9 ms
Donc:
kevin@zipslack:~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/packets received/
{printf("%dn", $4);}'
kevin@zipslack:~/tmp$ <-- Rien !!
Et le script s'activera toutes les heures et 17 minutes.
Mais
kevin@zipslack:~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/received/
{printf("%dn", $4);}'
4 <-- C'est plus normal
kevin@zipslack:~/tmp$
A tester, amha.
if [ $TEST_PING -eq 0 ]; then
expect << EOS
spawn telnet einstein.systella.fr
Un ssh serait plus elegant, non?
Non, il ne peut être attaqué que par telnet et le mot de passe est
figé. Comme il est dans la doc et utilisable que sur l'interface
LAN, je ne vois pas bien la peine de le cacher.
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est
pas du linux?). Genre un halt au lieu d'un reboot.
Non, c'est un routeur. Et cela plante _avant_ ou _au_ lancement du
script. En fait, j'ai écrit ce script parce que de temps en temps,
une trame bizarre arrive du WAN et fait planter sauvagement le
routeur...
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Kevin Denis écrivait dans fr.comp.os.linux.moderated :
Le 23-12-2004, JKB a écrit :
Sauf que depuis quelques temps, je remarque que ce ~@#{^ plantage se produit toujours à xxh17 (toutes les 17 minutes de chaque heure), heure à laquelle se déclanche cron.hourly. Je n'ai qu'un seul script qui vérifie si la connexion ADSL est toujours active et qui reboote le cas échéant le modem.
Question bete: Et si tu desactives ce script?
Je ne sais pas. Le truc n'est pas reproductible. Pour information, j'ai fait tourner toute la nuit ce script en boucle dans un run-parts sans souci !
Autre truc: chez moi ping n'affiche pas packets received, mais: 4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rayleigh:[~] > ping -c 4 www.nerim.fr PING www0.nerim.net (62.4.16.81): 56 data bytes 64 bytes from 62.4.16.81: icmp_seq=0 ttl` time1.3 ms 64 bytes from 62.4.16.81: icmp_seq=1 ttl` time%.1 ms 64 bytes from 62.4.16.81: icmp_seq=2 ttl` time$.5 ms 64 bytes from 62.4.16.81: icmp_seq=3 ttl` time#.9 ms
Donc: :~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/packets received/ {printf("%dn", $4);}' :~/tmp$ <-- Rien !! Et le script s'activera toutes les heures et 17 minutes.
Mais :~/tmp$ ping -c 4 172.16.5.5 2>&1 | awk '/received/ {printf("%dn", $4);}' 4 <-- C'est plus normal :~/tmp$ A tester, amha.
if [ $TEST_PING -eq 0 ]; then expect << EOS spawn telnet einstein.systella.fr
Un ssh serait plus elegant, non?
Non, il ne peut être attaqué que par telnet et le mot de passe est figé. Comme il est dans la doc et utilisable que sur l'interface LAN, je ne vois pas bien la peine de le cacher.
peut etre le 'do reboot' qui fait quelque chose de mauvais? (C'est pas du linux?). Genre un halt au lieu d'un reboot.
Non, c'est un routeur. Et cela plante _avant_ ou _au_ lancement du script. En fait, j'ai écrit ce script parce que de temps en temps, une trame bizarre arrive du WAN et fait planter sauvagement le routeur...
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Alain Montfranc
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Les symptomes sont il un arret brutal des logs, les process qui ne
peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais
une cnx n'abouti jamais dessus) ?
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne
peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais
une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux
pas dire plus. C'est un peu comme si le noyau partait dans une
boucle infinie. Je n'ai aucun moyen d'en savoir plus...
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Alain Montfranc
JKB a exposé le 23/12/2004 :
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB a exposé le 23/12/2004 :
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne
peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais
une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux
pas dire plus. C'est un peu comme si le noyau partait dans une
boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est
difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
JKB a exposé le 23/12/2004 :
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
J'ai tout essayé. J'ai l'impression que le problème est apparu avec un 2.4.21 ou quelque chose comme ça, mais j'ai dû le patcher pour des raisons de sécurité. Depuis, j'ai essayé avec plus ou moins de bonheur : la fin de la série 2.4, puis les 2.6 officiels. Aujourd'hui, je tourne avec un 2.6.9 d'origine debian (la machine est en debian testing).
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
JKB a exposé le 23/12/2004 :
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne
peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais
une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux
pas dire plus. C'est un peu comme si le noyau partait dans une
boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est
difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
J'ai tout essayé. J'ai l'impression que le problème est apparu avec
un 2.4.21 ou quelque chose comme ça, mais j'ai dû le patcher pour
des raisons de sécurité. Depuis, j'ai essayé avec plus ou moins
de bonheur : la fin de la série 2.4, puis les 2.6 officiels.
Aujourd'hui, je tourne avec un 2.6.9 d'origine debian (la machine
est en debian testing).
À froid, j'ai l'impression que le noyau se marche dessus à un moment
ou un autre sur un appel système parce que le processeur est un peu lent
(mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver
hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas
planter les connexions réseau sur les U1.
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
JKB a exposé le 23/12/2004 :
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Alain Montfranc écrivait dans fr.comp.os.linux.moderated :
Les symptomes sont il un arret brutal des logs, les process qui ne peuvent plus forker (ex: serveur http : le port 80 reste ouvert mais une cnx n'abouti jamais dessus) ?
Arrêt brutal des logs. La machine ne répond plus à rien. Je ne peux pas dire plus. C'est un peu comme si le noyau partait dans une boucle infinie. Je n'ai aucun moyen d'en savoir plus...
J'ai exactement le meme sur une vielle redhat dont le noyau est difficile a upgrader (beacuse drivers dont j'ai pas les sources)
Tu es en quelle version de noyau ?
J'ai tout essayé. J'ai l'impression que le problème est apparu avec un 2.4.21 ou quelque chose comme ça, mais j'ai dû le patcher pour des raisons de sécurité. Depuis, j'ai essayé avec plus ou moins de bonheur : la fin de la série 2.4, puis les 2.6 officiels. Aujourd'hui, je tourne avec un 2.6.9 d'origine debian (la machine est en debian testing).
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Julien BLACHE
JKB wrote:
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien sauf au ping)
JB.
-- «Big boss, est-ce que le firewall kille le Supersedes ? » En français pour MB: «Chef, est ce que le coupe-feu est étanche au "change pas de main, je sens que ça vient" ? » -+- JCR in: Guide du Cabaliste Usenet - Usenet est-il inflammable ? -+-
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB <knatschke@chezmoi.com> wrote:
À froid, j'ai l'impression que le noyau se marche dessus à un moment
ou un autre sur un appel système parce que le processeur est un peu lent
(mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver
hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas
planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement
similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien
sauf au ping)
JB.
--
«Big boss, est-ce que le firewall kille le Supersedes ? »
En français pour MB: «Chef, est ce que le coupe-feu est étanche au
"change pas de main, je sens que ça vient" ? »
-+- JCR in: Guide du Cabaliste Usenet - Usenet est-il inflammable ? -+-
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien sauf au ping)
JB.
-- «Big boss, est-ce que le firewall kille le Supersedes ? » En français pour MB: «Chef, est ce que le coupe-feu est étanche au "change pas de main, je sens que ça vient" ? » -+- JCR in: Guide du Cabaliste Usenet - Usenet est-il inflammable ? -+-
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Julien BLACHE écrivait dans fr.comp.os.linux.moderated :
JKB wrote:
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien sauf au ping)
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent parfaitement (la carte raid ne renvoie aucune erreur). La machine fonctionne très bien jusqu'à un plantage _total_ (même plus de ping ni de réponse au clavier).
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 23-12-2004, à propos de
Re: Cron et plantage serveur,
Julien BLACHE écrivait dans fr.comp.os.linux.moderated :
JKB <knatschke@chezmoi.com> wrote:
À froid, j'ai l'impression que le noyau se marche dessus à un moment
ou un autre sur un appel système parce que le processeur est un peu lent
(mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver
hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas
planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement
similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien
sauf au ping)
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent
parfaitement (la carte raid ne renvoie aucune erreur). La machine
fonctionne très bien jusqu'à un plantage _total_ (même plus de ping
ni de réponse au clavier).
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 23-12-2004, à propos de Re: Cron et plantage serveur, Julien BLACHE écrivait dans fr.comp.os.linux.moderated :
JKB wrote:
À froid, j'ai l'impression que le noyau se marche dessus à un moment ou un autre sur un appel système parce que le processeur est un peu lent (mais pourquoi ne que provenant de cron ?), un peu comme le bug du driver hme de la version sparc où il fallait rajouter un usleep(1); pour ne pas planter les connexions réseau sur les U1.
A ta place, j'insisterai sur les disques, j'ai eu un comportement similaire il y a quelques jours avec un disque défaillant.
(machine lentissime, voire machine plantée ne répondant plus à rien sauf au ping)
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent parfaitement (la carte raid ne renvoie aucune erreur). La machine fonctionne très bien jusqu'à un plantage _total_ (même plus de ping ni de réponse au clavier).
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Emmanuel Florac
Le Thu, 23 Dec 2004 22:09:48 +0000, JKB a écrit :
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent parfaitement (la carte raid ne renvoie aucune erreur). La machine fonctionne très bien jusqu'à un plantage _total_ (même plus de ping ni de réponse au clavier).
Je sais que c'est stupide, mais j'ai eu un cas similaire il y a quelques mois. On a changé TOUT le hardware (carte mère, carte RAID, etc) mais la machine continuait à se planter sur un cron quotidien quasiment à chaque fois. Il se trouve que le script était écrit en Csh; en le récrivant en pur bash la machine n'a plus JAMAIS planté...
-- Sutor ne ultra Crepidam.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le Thu, 23 Dec 2004 22:09:48 +0000, JKB a écrit :
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent
parfaitement (la carte raid ne renvoie aucune erreur). La machine
fonctionne très bien jusqu'à un plantage _total_ (même plus de ping
ni de réponse au clavier).
Je sais que c'est stupide, mais j'ai eu un cas similaire il y a quelques
mois. On a changé TOUT le hardware (carte mère, carte RAID, etc) mais la
machine continuait à se planter sur un cron quotidien quasiment à
chaque fois. Il se trouve que le script était écrit en Csh; en le
récrivant en pur bash la machine n'a plus JAMAIS planté...
--
Sutor ne ultra Crepidam.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Ce n'est pas du tout ça. Les disques sont bons et fonctionnent parfaitement (la carte raid ne renvoie aucune erreur). La machine fonctionne très bien jusqu'à un plantage _total_ (même plus de ping ni de réponse au clavier).
Je sais que c'est stupide, mais j'ai eu un cas similaire il y a quelques mois. On a changé TOUT le hardware (carte mère, carte RAID, etc) mais la machine continuait à se planter sur un cron quotidien quasiment à chaque fois. Il se trouve que le script était écrit en Csh; en le récrivant en pur bash la machine n'a plus JAMAIS planté...
-- Sutor ne ultra Crepidam.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Kevin Denis
ingredients. Make balls about the size of a baby?s fist (there should be one lying around for reference). Bake at 400°for about 25 minutes - or you could fry them in olive oil. Place the meatballs in the tomato gravy, and simmer for several hours. Serve on spaghetti. Accompany with green salad, garlic bread and red wine.
Newborn Parmesan
This classic Sicilian cuisine can easily be turned into Eggplant Parmesan If you are planning a vegetarian meal. Or you could just as well use veal - after all, you have to be careful - Sicilians are touchy about their young family members...
6 newborn or veal cutlets Tomato gravy (see index) 4 cups mozzarella, 1cup parmesan, 1cup romano Seasoned bread crumbs mixed with parmesan romano salt pepper oregano garlic powder chopped parsley Flour eggwash (eggs and milk) Peanut oil for frying.
Pound the cutlets. Dredge in flour, eggs, then the bread crumb mixture. Fry till golden brown in 350° peanut oil. In a baking pan, place a layer of gravy, then one of meat, gravy, and cheese. Another layer each of meat, gravy, and cheese. Then bake at 350° for 45 minutes. Serve on hot pasta with romano cheese.
Southern Fried Small-fry
Tastes like fried chicken, which works just as well. In fact you may want to practice cutting up whole chickens for frying before you go for the real thing. Whole chicken is much more efficient and inexpensive than buying pieces.
1 tiny human,
ingredients.
Make balls about the size of a baby?s fist
(there should be one lying around for reference).
Bake at 400°for about 25 minutes -
or you could fry them in olive oil.
Place the meatballs in the tomato gravy, and simmer for several hours.
Serve on spaghetti.
Accompany with green salad, garlic bread and red wine.
Newborn Parmesan
This classic Sicilian cuisine can easily be turned into Eggplant Parmesan
If you are planning a vegetarian meal. Or you could just as well use veal -
after all, you have to be careful - Sicilians are touchy about their young
family members...
6 newborn or veal cutlets
Tomato gravy (see index)
4 cups mozzarella, 1cup parmesan, 1cup romano
Seasoned bread crumbs mixed with
parmesan
romano
salt
pepper
oregano
garlic powder
chopped parsley
Flour
eggwash (eggs and milk)
Peanut oil for frying.
Pound the cutlets.
Dredge in flour, eggs, then the bread crumb mixture.
Fry till golden brown in 350° peanut oil.
In a baking pan, place a layer of gravy,
then one of meat, gravy, and cheese.
Another layer each of meat, gravy, and cheese.
Then bake at 350° for 45 minutes.
Serve on hot pasta with romano cheese.
Southern Fried Small-fry
Tastes like fried chicken, which works just as well.
In fact you may want to practice cutting up whole chickens
for frying before you go for the real thing.
Whole chicken is much more efficient and inexpensive than buying pieces.
ingredients. Make balls about the size of a baby?s fist (there should be one lying around for reference). Bake at 400°for about 25 minutes - or you could fry them in olive oil. Place the meatballs in the tomato gravy, and simmer for several hours. Serve on spaghetti. Accompany with green salad, garlic bread and red wine.
Newborn Parmesan
This classic Sicilian cuisine can easily be turned into Eggplant Parmesan If you are planning a vegetarian meal. Or you could just as well use veal - after all, you have to be careful - Sicilians are touchy about their young family members...
6 newborn or veal cutlets Tomato gravy (see index) 4 cups mozzarella, 1cup parmesan, 1cup romano Seasoned bread crumbs mixed with parmesan romano salt pepper oregano garlic powder chopped parsley Flour eggwash (eggs and milk) Peanut oil for frying.
Pound the cutlets. Dredge in flour, eggs, then the bread crumb mixture. Fry till golden brown in 350° peanut oil. In a baking pan, place a layer of gravy, then one of meat, gravy, and cheese. Another layer each of meat, gravy, and cheese. Then bake at 350° for 45 minutes. Serve on hot pasta with romano cheese.
Southern Fried Small-fry
Tastes like fried chicken, which works just as well. In fact you may want to practice cutting up whole chickens for frying before you go for the real thing. Whole chicken is much more efficient and inexpensive than buying pieces.
