Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Comment provoquer, volontairement, un crash de linux ?

Comment provoquer, volontairement, un crash de linux ?

9 réponses
Avatar
Yann Cohen
Bonjour,

En fait je dois envoyer loin loin d'ici une machine fonctionnant sous
Debian lenny.

L'appli sur cette machine plante de proche en proche n=C3=A9cessitant un
long long d=C3=A9placement pour appuyer sur le bouton marche arr=C3=AAt...
(fr=C3=A9quence de type une fois tous les 15 jours al=C3=A9atoirement).

Donc pour, dans un premier temps, =C3=A9viter ces d=C3=A9placements et en t=
ablant
sur un crash syst=C3=A8me, j'ai mis en place dans sysctl.conf une ligne
kernel.panic =3D 20 qui est pr=C3=A9vue pour un reboot au bout de 20 second=
es
apr=C3=A8s le crash.

Avant d'envoyer la CPU sur site et comme pour l'instant je n'ai pas
r=C3=A9ussi =C3=A0 mettre en place un banc de test qui r=C3=A9ussi =C3=A0 t=
ous les coups le
plantage du syst=C3=A8me complet (6 mois de fonctionnement : deux cas de
plantage al=C3=A9atoire), je cherche =C3=A0 "voir" fonctionner le reboot
automatique sur plantage syst=C3=A8me...

D'o=C3=B9 ma question : existe-t-il une m=C3=A9thode pour simuler ou provoq=
uer un
crash syst=C3=A8me ?

Merci.

--
Yann.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20111206085049.57406a5e@lurr069-l.ianco.homelinux.org
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Yves Rutschle
On Tue, Dec 06, 2011 at 08:50:49AM +0100, Yann Cohen wrote:
L'appli sur cette machine plante de proche en proche nécessitant un
long long déplacement pour appuyer sur le bouton marche arrêt...
(fréquence de type une fois tous les 15 jours aléatoirement).



Je ne comprend pas: c'est l'appli ou le noyau qui crash?

D'où ma question : existe-t-il une méthode pour simuler ou provoquer un
crash système ?



cat /dev/random > /proc/kcore ?

Mais plus sérieusement, ce qu'il te faut, c'est une carte
watchdog.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yann Cohen
Le Tue, 6 Dec 2011 09:08:06 +0100,
Yves Rutschle a écrit :

On Tue, Dec 06, 2011 at 08:50:49AM +0100, Yann Cohen wrote:
> L'appli sur cette machine plante de proche en proche nécessitant un
> long long déplacement pour appuyer sur le bouton marche arrêt ...
> (fréquence de type une fois tous les 15 jours aléatoirement).

Je ne comprend pas: c'est l'appli ou le noyau qui crash?


Et bien, les rapports des observateurs envoyés sur place me laisse un
doute : le système ne répond plus au niveau réseau (mêm e le ping n'est
plus accessible), l'appli est silencieuse, plus de prompte console, mais
la console n'afficherai pas l'écran de crash.


> D'où ma question : existe-t-il une méthode pour simuler ou
> provoquer un crash système ?

cat /dev/random > /proc/kcore ?


Ok je vais essayer de ce pas !


Mais plus sérieusement, ce qu'il te faut, c'est une carte
watchdog.



Oui, c'est une piste que j'envisage depuis un certain temps d'autant
plus que la CPU est une geode LX avec un watchdog physique intégrà ©.

Mais l'ajout du paquet watchdog ou la compilation du noyau avec
explicitement la prise en compte du compagnon de la geode ne donne
satisfaction : aujourd'hui aucun /dev/watchdog créer et la
documentation glanée sur le net ne m'a pas permis d'avancer beaucoup
sur ce point...

Coté applicatif multi-thread, j'ai mis en place un pseudo watchdog
applicatif : si absence de signalisation du fonctionnement des threads
critique alors reboot de la cible.

Je verrai bien qui déclenche : l'appli ou non (enfin si elle a le temps
de tracer ses log...).

Enfin le caractère exceptionnel de ce comportement rend "complexe"
l'analyse puisqu'il s'agit un seul site sur plus d'une centaine et sur
lequel tous les éléments matériel ont déjà ét é changés.

Y.



--
Yann.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Tue, 6 Dec 2011 09:46:43 +0100
Yann Cohen wrote:

> Je ne comprend pas: c'est l'appli ou le noyau qui crash?
Et bien, les rapports des observateurs envoyés sur place me laisse un
doute : le système ne répond plus au niveau réseau (mà ªme le ping n'est
plus accessible), l'appli est silencieuse, plus de prompte console, mais
la console n'afficherai pas l'écran de crash.



Ca doit-être la raison pour laquelle le watchdog ne réagit pas:
l'appli plante une partie du micro, mais il reste "opérationnel"
(d'ailleurs, ça serait intéressant de voir si on garde la poss. de
se connecter en SSH, auquel cas fini les déplacements).

Maintenant, la 1ère chose à faire serait d'avoir une appli stable ...

Déjà, as-tu fait un memtest de la Cte mère? (s/s entendu, ex iste-t'il
des conditions particulières s/s lesquelles l'appli se met à
consommer de la RAM?)

Sinon, si cette appli reste en fonctionnement 24/7, une autre
solution serait d'utiliser un cron pour la relancer à intervalles
réguliers.

Une autre encore serait de faire tourner l'appli dans une VM et de
la relancer lorsqu'elle ne répond plus (un genre de HA à la hache :)

Quelle type de traitement fournit cette appli?

…
Enfin le caractère exceptionnel de ce comportement rend "complexe"
l'analyse puisqu'il s'agit un seul site sur plus d'une centaine et sur
lequel tous les éléments matérielS ont déjà à ©té changés.



Certaines cartes réseau (Rhine-II, donc pas mal de D-link) ont une
fâcheuse tendance à mal se comporter et nécessitent un ifdow n/ifup
régulier pour continuer à fonctionner correctement.

--
printk("ufs_read_super: fucking Sun blows men");
-- /usr/src/linux/fs/ufs/ufs_super.c

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Frédéric Massot
Yann Cohen wrote:

Je ne comprend pas: c'est l'appli ou le noyau qui crash?


Et bien, les rapports des observateurs envoyés sur place me laisse un
doute : le système ne répond plus au niveau réseau (même le ping n'est
plus accessible), l'appli est silencieuse, plus de prompte console, mais
la console n'afficherai pas l'écran de crash.





Tu peux vérifier que le système tourne toujours en demandant à rsyslog
de laisser des marques dans les logs.

Dans le fichier "/etc/rsyslog.conf", tu dé-commentes la ligne :

$ModLoad immark


Et pour que ces marques soient inscrites de façon inconditionnelles tu
ajoutes :

$ActionWriteAllMarkMessages on

Au dessus du bloc :

*.=info;*.=notice;*.=warn;
auth,authpriv.none;
cron,daemon.none;
mail,news.none -/var/log/messages

Tu auras une marque "-- MARK --" dans le fichier "/var/log/messages"
toutes les 20 minutes.

--
============================================= | FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
==========================Þbian=GNU/Linux==
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Grégory Bulot
Bonjour, Bonsoir,

Le Tue, 6 Dec 2011 09:08:06 +0100, Yves Rutschle, vous avez écrit :

On Tue, Dec 06, 2011 at 08:50:49AM +0100, Yann Cohen wrote:
> L'appli sur cette machine plante de proche en proche nécessitant un
> long long déplacement pour appuyer sur le bouton marche arrêt...
> (fréquence de type une fois tous les 15 jours aléatoirement).

Je ne comprend pas: c'est l'appli ou le noyau qui crash?




J'adore cette façon de ne pas répondre à la question initiale,
heureusement que plus bas vous proposez une solution. Malheureusement
les contributeurs suivant de ce fil ont oublié de lire le sujet ...


Si l'auteur avait demandé "pouvez-vous me dire pourquoi mon appli
plante", il se serait fait incendier sur environ 500 posts pendant 2-3
semaines.

C'est dommage, je trouvais la question de l'auteur intéressante.





--
Cordialement
Grégory BULOT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yann Cohen
Le Tue, 6 Dec 2011 09:08:06 +0100,
Yves Rutschle a écrit :

[...]
> D'où ma question : existe-t-il une méthode pour simuler ou
> provoquer un crash système ?

cat /dev/random > /proc/kcore ?


Non !
marche pas...

Yann.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Matthieu
On Tue, Dec 6, 2011 at 11:57, Yann Cohen wrote:
Le Tue, 6 Dec 2011 09:08:06 +0100,
Yves Rutschle a écrit :

[...]
> D'où ma question : existe-t-il une méthode pour simuler ou
> provoquer un crash système ?

cat /dev/random > /proc/kcore ?


Non !
marche pas...



Bonjour,

"echo c > /proc/sysrq-trigger" devrait faire l'affaire.


Yann.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAK6ghz-nu0DycjNdPXd92Gsa1wcjiLUEHBE1BFQ-FN67d7rb+
Avatar
Yves Rutschle
On Tue, Dec 06, 2011 at 10:31:24AM +0100, Grégory Bulot wrote:
J'adore cette façon de ne pas répondre à la question initiale,
heureusement que plus bas vous proposez une solution. Malheureusement
les contributeurs suivant de ce fil ont oublié de lire le sujet ...



J'imagine que quand on te demande si tu as l'heure, tu
réponds "oui".

Le but de l'auteur n'est pas planter son système, c'est
qu'il redémarre correctement lorsqu'il plante. Comme
d'habitude, on essaie d'extrapoler le besoin derrière la
question.

Je t'invite à lire
http://catb.org/~esr/faqs/smart-questions.html#symptoms
(en français au 3.8 ici:
http://1100f.free.fr/smart-questions-fr.pdf).

Si l'auteur avait demandé "pouvez-vous me dire pourquoi mon appli
plante", il se serait fait incendier sur environ 500 posts pendant 2-3
semaines.



Non, la question que j'ai l'impression qu'il voulait poser,
c'est: "Mon serveur semble planter [description des
symptômes], comment résoudre ce problème sachant qu'on ne
peut pas toucher à l'application".

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Yves Rutschle
On Tue, Dec 06, 2011 at 09:46:43AM +0100, Yann Cohen wrote:
Et bien, les rapports des observateurs envoyés sur place me laisse un
doute : le système ne répond plus au niveau réseau (même le ping n'est
plus accessible), l'appli est silencieuse, plus de prompte console, mais
la console n'afficherai pas l'écran de crash.



Ok, ça ressemble donc bien à un crash de noyau ou un
problème matériel. Si ça plante "suffisament", on peut se
retrouver figé et ne pas arriver à afficher l'écran de
crash. Mais si ça plante à ce point, la solution en
demandant au noyau de redémarrer 20 secondes après son crash
ne va pas marcher non plus (ça ne peut marcher que si le
noyau marche encore suffisament). Et aucune solution à base
de watchdog logiciel ne suffira.

> Mais plus sérieusement, ce qu'il te faut, c'est une carte
> watchdog.

Oui, c'est une piste que j'envisage depuis un certain temps d'autant
plus que la CPU est une geode LX avec un watchdog physique intégré.



Désolé, je ne connais pas ces choses là. Après compilation
et chargement du pilote tu ne le vois pas dans
/proc/devices?

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/