Kernel panic - not syncing: Fatal exception in interrupt

Support Debian
#1

Bonsoir,

Depuis quelques jours, j’ai eu plusieurs plantages de mon serveur perso sous Debian Wheezy. Des fois, mon serveur est inaccessible (impossible de se connecter en SSH). Des fois, j’ai des erreurs “Segmentation fault” sur plusieurs commandes (et même aptitude) et seul un reboot resolve le problème.

Aujourd’hui, j’ai eu le même problème au moment où j’étais connecter en SSH. J’ai vu les messages d’erreur suivants :

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.854279] general protection fault: 0000 [#1] SMP 

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.855926] Stack:

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.856153] Call Trace:

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.856724] Code: 7f 10 02 0f 95 c2 31 c0 8d 54 52 01 8b 0c 86 39 0c 87 75 0a 48 ff c0 39 c2 7f f1 31 c0 c3 19 c0 83 c8 01 c3 48 8b 05 25 e8 3d 00 <89> 87 a0 00 00 00 f0 ff 8f a4 00 00 00 c3 48 85 ff b0 01 74 33 

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.872084] Kernel panic - not syncing: Fatal exception in interrupt
Write failed: Broken pipe

Quelqu’un a une idée sur le problème?

Merci d’avance.

#2

Teste le matos, au moins memtest86 pour la RAM, car ça me paraît pas bon signe…
Tu peux éventuellement chopper un systemrescuecd, ainsi que des outils SMART (smartmontools ? présent dans les dépots Debian)

#3

[quote=“UgM”]Bonsoir,

Depuis quelques jours, j’ai eu plusieurs plantages de mon serveur perso sous Debian Wheezy. Des fois, mon serveur est inaccessible (impossible de se connecter en SSH). Des fois, j’ai des erreurs “Segmentation fault” sur plusieurs commandes (et même aptitude) et seul un reboot resolve le problème.

Aujourd’hui, j’ai eu le même problème au moment où j’étais connecter en SSH. J’ai vu les messages d’erreur suivants :

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.854279] general protection fault: 0000 [#1] SMP 

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.855926] Stack:

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.856153] Call Trace:

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.856724] Code: 7f 10 02 0f 95 c2 31 c0 8d 54 52 01 8b 0c 86 39 0c 87 75 0a 48 ff c0 39 c2 7f f1 31 c0 c3 19 c0 83 c8 01 c3 48 8b 05 25 e8 3d 00 <89> 87 a0 00 00 00 f0 ff 8f a4 00 00 00 c3 48 85 ff b0 01 74 33 

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.872084] Kernel panic - not syncing: Fatal exception in interrupt
Write failed: Broken pipe

Quelqu’un a une idée sur le problème?

Merci d’avance.[/quote]

Vérifie dans tes logs systèmes et kernel, vérifie le matériel tel que disque dur (si pas de raid en place) mais je pense pas que tu trouvera grand chose, si tu as du monitoring complet penche toi dessus pour voir les consommation de ressources anormales.

Après c’est malheureusement avec un peu à tâtons que tu va devoir chercher pour trouver le coupable, mais en règle générale un kernel panic n’arrive jamais comme ça par magie :think:

Qu’as-tu fais dernièrement sur ton serveur, déploiement d’une nouvelle application, mises à jour ?

#4

Salut,

Je pencherai (à première vu et faute d’autre éléments) également pour les barrettes.
Inverses/trifouille/change
Heu sinon, l’espace disque est-il, suffisant …

#5

Hier, j’ai déjà vérifier mes disques avec fsck. Il ne semble pas avoir un problème de ce coté là. Et de l’espace disque, j’ai qu’un disque qui dépasse le 50% et il ne contient pas la partition système.

Dans mes logs, je ne vois que des Kernel Panic et Segment Fault qui ne soient pas normaux! Récemment, j’ai installé shellinbox et le module intl de php.

Là, je suis en train de tester mes barrettes avec memtest86+. À suivre! (ça risque d’être long je pense!)

#6

Bon, j’ai déjà plus de 100 erreurs avec memtest. Et c’est pas fini. J’espère que ce sont pas mes 2 barrettes qui ont ces erreurs.

#7

Perso, je préférerai devoir changer la RAM, plutôt que la carte mère, ou autre …

Aux prix ou elles sont, hein … :wink:

#8

C’est sur. De plus mes ram sont encore sous garantie mais j’aimerai pouvoir faire tourner mon serveur sur une barrette.

#9

Lorsque je teste mes barrettes de RAM un par un, je n’ai pas d’erreur du tout.
Bon, je ne suis pas aller jusqu’au bout des tests (ça ma petite femme à besoin des données sur le serveur.) Du coup, je fais tourner mon serveur avec une seule barrette pour cette nuit. Par contre, mysql ne demarre plus (depuis que ça planté ce matin). Je pense que c’est lié à ce problème. Dans le log syslog :

J’ai tenté une réinstallation de mysql-server-5.5 mais toujours impossible de le démarrer. :013

#10

Le problème ne viendrait donc pas de l’une des barrettes, mais de l’un des slots sur la carte mère ?

Car à partir du moment où memtest86 te sort une dizaine d’erreurs, tu peux arrêter le test, ça signifie qu’il y a un problème de matos. Sinon je crois que memtest c’est un peu comme arkanoïd, personne n’est allé jusqu’au bout…

Le message d’erreur de mysql est identique à chaque fois que tu le lances ? Car c’est encore symptomatique d’un problème de mémoire corrompue.

#11

[quote=“Zbf”]Le problème ne viendrait donc pas de l’une des barrettes, mais de l’un des slots sur la carte mère ?
Car à partir du moment où memtest86 te sort une dizaine d’erreurs, tu peux arrêter le test, ça signifie qu’il y a un problème de matos. Sinon je crois que memtest c’est un peu comme arkanoïd, personne n’est allé jusqu’au bout…
[/quote]

Je testerai le 2ème slots demain.

[quote=“Zbf”]
Le message d’erreur de mysql est identique à chaque fois que tu le lances ? Car c’est encore symptomatique d’un problème de mémoire corrompue.[/quote]
Je pensais aussi mais comment résoudre cette corruption de mémoire? Y a une solution?

#12

bonjour,
c’est gratuit,
avez-vous agrandi shmmax,
il est à son maxi!
il y a du swap?

Oct 30 18:55:52 tuxgasy mysqld: It is possible that mysqld could use up to
Oct 30 18:55:52 tuxgasy mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346682 K bytes of memor
y

A+
JB1

#13

La solution, c’est de ne pas utiliser la barrette défectueuse (ou le slot défectueux), je ne parlais que de ça.

#14

bonjour,
sur cette MB, les barrettes fonctionnent par pair?

pour utiler avec memtest,
je retire les barrettes,
je souffle trés, trés fort dans les slots mémoire (sans postillonner)
je passe un petit coup de gomme sur les connecteurs des barrettes, (pas comme une brute)
je réinstalle
je lance memtest
à la 1°erreur je regarde sur quelle barrette,
je permutte pour confirmer la barrette

dans le temps memtest avait une configuration spéciphique pour s’affranchir d’un certain type d’erreur!
A+
JB1
:033

#15

J’ai refais 2 tests les slots aujourd’hui avec une seule de mes barrettes. Pas un seul erreur.
Mais lorsque j’ai remis la 2ème barrette, le pc ne démarre plus et j’entend un bip (qui signale un problème matériel?). En la retirant, le pc marche mieux. Je pense que j’ai trouvé le coupable.

Je referai un test demain pour être sûr. Par contre, mysql ne démarre toujours pas. Je pense que je vais devoir le réinstaller complétement (j’espère que mon dernier backup est valide).

Merci à tous pour les pistes. Bon soirée.

#16

Supprime le fichier /var/lib/mysql/ibdata1 (ou renomme le) et relance mysql.

#17

Toujours failed mais j’ai beaucoup moins d’erreur dans le log :

Oct 31 18:35:26 tuxgasy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [Note] Plugin 'FEDERATED' is disabled.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: The InnoDB memory heap is disabled
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Compressed tables use zlib 1.2.7
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Using Linux native AIO
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Initializing buffer pool, size = 128.0M
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Completed initialization of buffer pool
Oct 31 18:35:26 tuxgasy mysqld: InnoDB: The first specified data file ./ibdata1 did not exist:
Oct 31 18:35:26 tuxgasy mysqld: InnoDB: a new database to be created!
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Setting file ./ibdata1 size to 10 MB
Oct 31 18:35:26 tuxgasy mysqld: InnoDB: Database physically writes the file full: wait...
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Error: all log files must be created at the same time.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: All log files must be created also in database creation.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: If you want bigger or smaller log files, shut down the
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: database and make sure there were no errors in shutdown.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: Then delete the existing log files. Edit the .cnf file
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 InnoDB: and start the database again.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [ERROR] Plugin 'InnoDB' init function returned error.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [ERROR] Unknown/unsupported storage engine: InnoDB
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [ERROR] Aborting
Oct 31 18:35:26 tuxgasy mysqld:
Oct 31 18:35:26 tuxgasy mysqld: 131031 18:35:26 [Note] /usr/sbin/mysqld: Shutdown complete
Oct 31 18:35:26 tuxgasy mysqld:
Oct 31 18:35:26 tuxgasy mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Oct 31 18:35:39 tuxgasy postfix/smtpd[5312]: connect from tuxgasy.fr[127.0.0.1]
Oct 31 18:35:39 tuxgasy postfix/smtpd[5312]: disconnect from tuxgasy.fr[127.0.0.1]
Oct 31 18:35:39 tuxgasy dovecot: imap-login: Aborted login (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1
, TLS, session=<yRTQ4Azq8wB/AAAB>
Oct 31 18:35:40 tuxgasy /etc/init.d/mysql[5350]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.
cnf ping' resulted in
Oct 31 18:35:40 tuxgasy /etc/init.d/mysql[5350]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Oct 31 18:35:40 tuxgasy /etc/init.d/mysql[5350]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/m
ysqld.sock' (2)'
Oct 31 18:35:40 tuxgasy /etc/init.d/mysql[5350]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.soc
k' exists!
Oct 31 18:35:40 tuxgasy /etc/init.d/mysql[5350]:
#18

Salut,

Intéressant, tiens … :bulb:

[quote=“UgM”][ERROR] Plugin ‘InnoDB’ init function returned error.
…
error: 'Can’t connect to local MySQL server through socket '/var/run/mysqld/m
[/quote]

J’ai connu cela sur un serveur, distant.

#19

[quote=“BelZéButh”]Salut,

Intéressant, tiens … :bulb:

[quote=“UgM”][ERROR] Plugin ‘InnoDB’ init function returned error.
…
error: 'Can’t connect to local MySQL server through socket '/var/run/mysqld/m
[/quote]

J’ai connu cela sur un serveur, distant.[/quote]

Et tu te rappelle comment t’as résolu le problème? (parce que ça m’intéresse beaucoup… :blush: )

#20

De mémoire (et cette dernière est bonne :wink: ) c’est ici : /etc/mysql/my.cnf -> qui te faut influencer/modifier quelques paramètres.

Pour ce faire, plus précisément il me faudrait aller, la_bas … (c’est encore en place, avec le lien (en commentaire) qui m’avait permis de résoudre ce souci)