Installer

Je suis programmeur depuis un certain temps maintenant, mais je suis toujours un peu flou sur les choses profondes et internes.

Maintenant. Je suis bien conscient que ce n'est pas une bonne idée non plus:

1. kill -9 un processus (mauvais)
2. tirez spontanément la fiche d'alimentation sur un ordinateur ou un serveur en cours d'exécution (pire)

Cependant, parfois vous devez simplement le faire. Parfois, un processus ne répond tout simplement pas, quoi que vous fassiez, et parfois un ordinateur ne répond tout simplement pas, quoi que vous fassiez.

Supposons un système exécutant Apache 2, MySQL 5, PHP 5 et Python 2.6.5 via mod_wsgi.

Remarque: Mac OS X m'intéresse le plus ici, mais une réponse qui concerne tout système UNIX pourrait m'aider.

Ma préoccupation

Chaque fois que je dois faire l'un ou l'autre, en particulier le second, je suis très inquiet pendant un certain temps que quelque chose ait été cassé. Un fichier quelque part pourrait être corrompu - qui sait quel fichier? Il y a plus de 1 000 000 de fichiers sur l'ordinateur.

J'utilise souvent OS X, je vais donc exécuter une opération "Vérifier le disque" via l'utilitaire de disque. Il ne signalera aucun problème, mais cela m'inquiète toujours.

Et si un fichier de configuration quelque part était foutu. Ou pire encore, que se passe-t-il si un fichier binaire quelque part est corrompu. Ou un fichier de script quelque part est corrompu maintenant. Que faire si du matériel est endommagé?

Et si je ne l'apprends que le mois prochain, dans un scénario critique, lorsque la corruption ou les dégâts provoquent une catastrophe?

Ou, que faire si des données précieuses sont déjà perdues?

Mon espoir

J'espère que ces préoccupations et inquiétudes ne sont pas fondées. Après tout, après avoir fait cela plusieurs fois auparavant, rien de vraiment mauvais ne s'est encore produit. Le pire est que j'ai dû réparer certaines tables MySQL, mais je ne semble pas avoir perdu de données.

Mais, si mes inquiétudes ne sont pas infondées et que des dommages réels pourraient survenir dans l'une ou l'autre des situations 1 ou 2, alors j'espère qu'il existe un moyen de le détecter et de le prévenir.

Mes questions)

Serait-ce parce que les systèmes d'exploitation modernes sont conçus pour garantir que rien ne soit perdu dans ces scénarios? Serait-ce parce que les logiciels modernes sont conçus pour garantir que rien ne soit perdu? Qu'en est-il de la conception matérielle moderne? Quelles sont les mesures en place lorsque vous retirez la fiche d'alimentation?

Ma question est, pour ces deux scénarios, qu'est-ce qui peut mal tourner exactement et quelles mesures devraient être prises pour y remédier?

J'ai l'impression qu'une chose qui peut mal tourner est que certains programmes n'ont peut-être pas vidé leurs données sur le disque, donc toutes les données très récentes qui étaient censées être écrites sur le disque (disons, quelques secondes avant la coupure d'alimentation) ) pourrait être perdu. Mais qu'en est-il au-delà de cela? Et ce problème même de perte de données de 5 secondes peut-il gâcher un système?

Qu'en est-il de la corruption de fichiers aléatoires se cachant quelque part dans l'immense forêt de fichiers sur mes disques durs?

Qu'en est-il des dommages matériels?

Qu'est-ce qui m'aiderait le plus

1. Descriptions détaillées de ce qui se passe en interne lorsque vous tuez -9 un processus ou mettez le système sous tension. (cela semble instantané, mais quelqu'un peut-il le ralentir pour moi?)

2. Explications de tout ce qui pourrait mal tourner dans ces scénarios, avec des probabilités (grossières bien sûr) (c'est-à-dire, c'est très peu probable, mais c'est probable) ...

3. Descriptions des mesures en place dans le matériel, les systèmes d'exploitation et les logiciels modernes pour éviter les dommages ou la corruption lorsque ces scénarios se produisent. (pour me réconforter)

4. Des instructions sur ce qu'il faut faire après un kill -9 ou une coupure d'alimentation, au-delà de "vérifier le disque", afin de s'assurer vraiment que rien n'est corrompu ou endommagé quelque part sur le lecteur.

5. Mesures qui peuvent être prises pour fortifier une configuration informatique afin que si quelque chose doit être tué ou que l'alimentation doit être coupée, tout dommage potentiel soit atténué.

6. Quelques informations sur les fichiers binaires - n'est-il pas vrai que le fichier binaire apache ou une bibliothèque pourrait avoir un octet aléatoire ou deux corrompus au milieu, cela ne sortirait pas et ne poserait de problème que plus tard? Comment puis-je m'assurer que cela ne s'est pas produit à la suite d'une coupure de courant ou d'une mise à mort?

Merci beaucoup!

En tirant sur l'alimentation, tout s'arrête en vol, sans avertissement. kill -9 a le même effet sur un seul processus, le terminant avec force par un SIGKILL .

Si un processus est tué par le noyau ou une panne de courant, il n'effectue aucun nettoyage. Cela signifie que vous pourriez avoir des fichiers à moitié écrits, des états incohérents ou des caches perdus. Vous n'avez généralement pas à vous soucier de tout cela à cause de la journalisation, de l'état de sortie et de la sauvegarde de la batterie.

Les fichiers temporaires dans / tmp disparaîtront automatiquement s'ils sont dans tmpfs, mais vous pouvez toujours avoir des fichiers de verrouillage spécifiques à l'application à supprimer, comme le verrou et .parentlock pour firefox.

La plupart des logiciels sont suffisamment intelligents pour réessayer une transaction s'ils n'enregistrent pas un état de sortie réussi. Un bon exemple de ceci est un système de messagerie typique. Si un message est remis, mais est interrompu au milieu, l'expéditeur réessayera plus tard jusqu'à ce qu'il réussisse.

Votre système de fichiers est probablement journalisé. Si vous déplacez ou écrivez un fichier et qu'il meurt en cours de route, le système de fichiers journalisé fera toujours référence à l'original. Le système de fichiers journalisé apportera des modifications de manière non destructive, laissant l'ancienne copie, puis référencera uniquement la nouvelle copie comme dernière étape avant de récupérer de l'espace les anciennes copies occupées sur le disque.

Désormais, si vous disposez d'une matrice RAID, elle dispose de toutes sortes de mémoires tampons pour augmenter les performances et assurer la fiabilité en cas de panne de courant. Votre système de fichiers ne connaîtra probablement pas les caches de l'appareil et leur état, il pense donc qu'une modification a été validée sur le disque, mais elle se trouve toujours quelque part dans le cache RAID. Alors, que se passe-t-il lorsque le pouvoir meurt? J'espère que vous avez une batterie fonctionnelle dans votre boîtier RAID et que vous la surveillez. Sinon, vous avez un système de fichiers corrompu à fsck.

Oui, quelques bits peuvent être corrompus dans un binaire, mais je ne m'inquiéterais pas autant de cela sur du matériel moderne. Si vous êtes vraiment paranoïaque, vous pouvez surveiller la santé de vos disques et RAID avec les outils appropriés, mais vous devriez quand même le faire. Effectuez des sauvegardes régulières et obtenez une alimentation sans coupure.

Dans un arrêt inattendu, les seuls fichiers qui devraient être corrompus sont les fichiers ouverts en écriture. Sur la plupart des systèmes à un instant donné, vous n'écrivez probablement pas dans un fichier. Probablement.

1 kill -9

est POSIX SIGKILL et dépend de l'implémentation. Le processus qui reçoit ce signal n'aura pas la possibilité de le gérer.

1 Éteindre

dépend du matériel. Les têtes se garent automatiquement sous l'impulsion du lecteur et tout dans votre cache d'écriture perd le rafraîchissement de la DRAM et se désintègre en une corruption irrémédiable en quelques secondes. La même chose se produit pour la mémoire système, le cache du processeur, les registres, etc.

De wdc.com (google: site: wdc.com Parking de tête de protection)

Coupure de courant: le disque dur est réinitialisé. La tête est garée dans la zone d'atterrissage en utilisant l'énergie de la broche. Le moteur de broche s'est arrêté.

2 - Qu'est-ce qui peut mal tourner

les fichiers laissés ouverts ne sont pas entièrement écrits. Si un fichier est ouvert en écriture, il y aura corruption de données. Les écritures de fichiers dans le matériel moderne sont rapides et les PC modernes ne sont normalement pas stressés avec IO. C'est comme marcher les yeux bandés sur une route de campagne tranquille. La plupart du temps, tout ira bien.

3 - contre-mesures

voir ci-dessus ce que font les disques.

Recherchez les systèmes de fichiers journalisés, ils sont normaux maintenant: http://en.wikipedia.org/wiki/Journaling_file_system

Un logiciel comme MS Word ou vi écrit dans un fichier temporaire plutôt que dans l'original. L'objectif est de ne jamais laisser le système dans un état où il n'y a pas de copie cohérente sur le disque.

Windows conserve des copies du registre (c'est tout simplement trop important) Wikipedia: "Windows 2000 conserve une copie alternative des ruches du registre (.ALT) et essaie d'y basculer en cas de corruption détectée" (je n'ai pas fait de support technique lourd depuis Win2k, donc je ne sais pas quels sont les nouveaux mécanismes de MS)

4 - que faire

Par ordre de difficulté (facile-difficile)

• Conserver les sauvegardes
• Vérifiez sur quoi vous travailliez en dernier
• Démarrez à partir d'un disque séparé et recherchez les dernières dates / heures modifiées pour comprendre ce que le système aurait pu faire au moment de l'accident
• Démarrez à partir d'un disque séparé et comparez les sommes md5 de tous vos fichiers à une copie hors ligne.

Conserver les sauvegardes est la réponse la plus appropriée, de bonnes sauvegardes devraient vous permettre de revenir à la version précédemment modifiée.

5

Puissance redondante? Formation des utilisateurs finaux? mettre du ruban adhésif et du carton sur le bouton d'alimentation?

6

À court de dysfonctionnements matériels, de pilotes de disque corrompus, d'un noyau de système d'exploitation cassé, d'une absence de sommes de contrôle ou de plantages lors des mises à niveau, les fichiers binaires et les bibliothèques ne sont pas ouverts en lecture-écriture afin qu'ils ne soient pas corrompus. Ça arrive, mais c'est rare.

Quant à un kill -9, cela envoie un signal au processus de "mourir" sur place. Le processus meurt (sauf s'il est en sommeil ininterrompu, auquel cas il devient un zombie). Aucun fichier n'est fermé, aucune donnée n'est écrite et le programme ne peut pas capter ce signal et faire autre chose. Pas de nettoyage, rien: il meurt.

Les systèmes de fichiers sont aujourd'hui très robustes; des choses comme XFS, JFS, ext3 et ext4 ont toutes des journaux et d'autres choses pour garder les métadonnées du système de fichiers intactes.

Les fichiers binaires comme Apache lui-même et d'autres ne sont pas susceptibles d'être corrompus par une perte soudaine de puissance ou par une mise à mort du système, car ils sont soit en mémoire soit en cours de lecture; s'ils sont lus (par exemple, Apache HTTP démarre par exemple), il est possible qu'une surtension puisse corrompre le binaire, mais cela semble peu probable.

J'ai un Mac Mini, les gens semblent aimer couper le froid (peu importe combien de fois je leur dis .....) et ça continue.

Pour la plupart, tant que vous ne comptez pas sur kill -9 ou que vous éteignez régulièrement, je ne m'inquiéterais pas trop. Les choses étaient bien pires dans le passé; Je m'inquiéterais plus (par exemple) de Solaris 2.6 que de Solaris 10 (et ainsi de suite).

Un "kill -9" ne synchronisera pas une opération d'E / S en attente. Ce n'est souvent pas un problème, mais si le système est soumis à une forte charge d'E / S, vous risquez de perdre des données.

C'est plus un problème avec les serveurs, où le contrôleur RAID (sans cache sauvegardé par batterie) peut mettre en cache les écritures et perdre vos données.

Edit : Une dernière chose ... si vous dépendez de lecteurs montés sur le réseau et avez des poignées de fichier ouvertes, vous risquez de laisser le fichier incohérent ou corrompu. Sous Windows, l'exemple classique de cela où vous voyez cela est lorsque les utilisateurs montent des fichiers Outlook PST sur un partage et perdent leur alimentation ou leur connectivité réseau.