# /!\ Fichiers de conf illisibles /!\

## vanille

Bonjour à tous,

je viens ici car je suis complétement perdue   :Crying or Very sad: 

Hier, mysql ne répondait plus, le fichier de conf n'était plus correct selon lui.

En effet, dans mon my.cnf il n'y a que des caractères illisibles. J'essaye de le modifier en root: impossible, read only system…

Je regarde mes fichiers de conf apache, idem: impossible de les lire, il n'y a que des hiéroglyphes dedans.

Ce que je ne comprends pas c'est que les dates de modification de tous ces fichiers sont toutes différentes et certains n'ont pas été modifiés depuis très longtemps, ils étaient corrects jusqu'à la semaine dernière.

On dirait que mon serveur les interprète mal...

A l'heure actuelle je ne peux ni lire le contenu réel, ni modifier le contenu de mes fichiers de conf.

Help me please!

----------

## El_Goretto

Tu as un (gros) problème avec ton stockage, il a l'air sacrément malade (défaillance hardware, source probable du montage en R/O). Regarde tes logs.

----------

## geekounet

Il est probable que ton système de fichier soit corrompu. Reboot en single, lance un fsck pour réparer tout ça, et restaure ton dernier backup valide.  :Smile: 

EDIT: oui check ton hardware avant comme le dit El_Goretto, autrement tu perdrais juste du temps.

----------

## vanille

Dans /var/log/debug :

collectd[2923]: rrd_update failed: cpu-6.rrd: opening 'cpu-6.rrd': Read-only file system

collectd[2923]: rrd_update failed: cpu-7.rrd: opening 'cpu-7.rrd': Read-only file system

collectd[2923]: rrd_update failed: traffic-lo.rrd: opening 'traffic-lo.rrd': Read-only file system

collectd[2923]: rrd_update failed: traffic-eth0.rrd: opening 'traffic-eth0.rrd': Read-only file system

collectd[2923]: rrd_update failed: traffic-eth1.rrd: opening 'traffic-eth1.rrd': Read-only file system

Dans /var/log/kern.log:

EXT3-fs error (device sda1): ext3_free_blocks: Freeing blocks not in datazone - block = 1680945250, count = 1

EXT3-fs error (device sda1): ext3_free_blocks: Freeing blocks not in datazone - block = 1630550323, count = 1

EXT3-fs error (device sda1): ext3_free_blocks: Freeing blocks not in datazone - block = 1667457841, count = 1

EXT3-fs error (device sda1) in ext3_reserve_inode_write: Journal has aborted

EXT3-fs error (device sda1) in ext3_truncate: Journal has aborted

EXT3-fs error (device sda1) in ext3_reserve_inode_write: Journal has aborted

EXT3-fs error (device sda2): ext3_free_blocks_sb: bit already cleared for block 121594280

EXT3-fs error (device sda2): ext3_free_blocks_sb: bit already cleared for block 122144775

EXT3-fs error (device sda2): ext3_free_blocks_sb: bit already cleared for block 122144776

En effet... cela ressemble à un problème de disque dur qui s'est mis en read only.

Je dois donc faire un fsck?

Par contre j'ai bien peur de ne pas avoir de backup   :Crying or Very sad:  et j'ai encore plus peur de rebooter la machine et qu'elle soit totalement bloquer (apache tourne toujours à l'heure actuelle)

----------

## El_Goretto

 *vanille wrote:*   

> Par contre j'ai bien peur de ne pas avoir de backup   et j'ai encore plus peur de rebooter la machine et qu'elle soit totalement bloquer (apache tourne toujours à l'heure actuelle)

 

"Live and learn" comme ils disent  :Smile: 

De toute façon, je ne vois pas l'intérêt de garder la machine "up" si tes données en bases sont HS. Car ça ne va pas aller en s'arrangeant.

Reboot sur un liveCD (pas d'arrêt électrique, donc on minimise les chances que le/les HDD(s) ne repartent pas), fais une extraction du contenu du disque avec un ddrescue, et ensuite, fais ce que tu veux pour récupérer tes données, comme un fsck & co.

----------

## xaviermiller

Tiens, je ne savais pas que "/!\" faisait partie des conventions de notre forum...  :Wink: 

----------

## vanille

Oui, j'ai inventé une nouvelle convention pour dire "Au secours je suis à la ramasse".

Mon serveur est hébergé, je ne peux pas mettre de livecd...

Un fsck à chaud c'est possible?

----------

## El_Goretto

Un fsck sur un système de fichier monté... c'est mal... très très mal...

Tu me diras, le tiens il est monté en R/O, de fait. 

"Ne se prononce pas". A toi d'évaluer les risques que tu es prêt à prendre.

De toute façon, ça ne va rien résoudre si tu as un problème hardware. Tant que tu n'as pas terminé le diagnostic...

----------

## geekounet

Reboot en single, ton FS sera toujours monté en RO mais avec rien d'autre qui tourne, fait un fsck, laisse le réparer auto (rien d'autre n'écrit vu que t'es en RO et ça ne plantera rien vu que plus rien ne tourne, donc ça gène pas), et reboot direct après. Si t'as encore des erreurs ensuite, ça sera encore plus probable d'être un problème hardware et tu pourras ouvrir un ticket chez ton hébergeur pour qu'il teste et remplace le matos endommagé (voire toute la machine).

<Ma vie>

Perso je suis aussi dans le cas d'un serveur dédié en fin de vie dont le controleur a des ratés sur un des 2 disques (en RAID1 soft) (et j'ai fait remplacer les hdd 5 ou 6 fois dans sa vie, heureusement c'est gratos), mais la flemme de faire réparer vu que je change d'hébergeur bientôt, et puis j'ai jusqu'à 6 mois de backups journaliers.  :Wink: 

</Ma vie>

----------

## vanille

Hello,

juste pour effectuer un petit retour sur l'incident.

Après avoir migré tous les éléments en production, j'ai effectué un redémarrage en mode rescue. 

Le problème provenait bien du disque dur, après un fsck peut concluant il s'avère qu'un de mes deux disques RAID avait laché... une intervention est en cours pour le changer.

La moralité de l'histoire: toujours faire des backups de ses serveurs!

En tout cas, merci à tous.

----------

