Mondes et sauvegardes

Corruption de données par arrêt forcé (Bouton Kill)

Relu le 6 septembre 2026 3 min de lecture

Stop et Kill terminent tous deux le processus. C'est la seule chose qu'ils ont en commun. L'un demande au jeu de finir ce qu'il fait d'abord ; l'autre ne demande rien du tout, et la différence entre ces deux idées est toute la raison pour laquelle l'un est sûr à utiliser chaque jour et l'autre un dernier recours.

Ce que chacun fait vraiment

Stop envoie au serveur un signal qu'il est construit pour gérer avec élégance : il déclenche la propre séquence d'arrêt de Minecraft, qui appelle save-all, vide chaque chunk modifié sur disque, ferme proprement les fichiers ouverts, et ne laisse le processus sortir qu'ensuite. C'est la même séquence qui s'exécute quand vous tapez /stop vous-même dans la console — le bouton du panel n'en est pas une version séparée ou amoindrie.

Kill envoie un signal que le processus ne peut ni intercepter ni auquel il ne peut répondre du tout — le système d'exploitation le termine immédiatement, en pleine instruction, quoi qu'il soit en train de faire. Si cet instant tombe justement au milieu de l'écriture du fichier de région d'un chunk sur disque, l'écriture s'arrête à mi-chemin, et ce qui reste sur disque n'est ni l'ancienne version de ce chunk ni la nouvelle — ce sont des octets des deux, ce qu'est réellement un fichier .mca corrompu au niveau des octets.

Quand utiliser lequel

SituationUtilisez
Redémarrage de routine, mise à jour, maintenanceStop
Redémarrages programmésStop
Console réellement sans réponse depuis plus de 60 secondes après avoir essayé StopKill, comme le dernier recours qu'il est censé être
« Ça semble lent mais la console répond encore »Stop — répondre lentement n'est pas la même chose que ne pas répondre
La corruption d'un arrêt forcé n'est pas toujours immédiate ni évidente

Un chunk coupé en pleine écriture ne fait pas toujours planter le serveur au chargement suivant — il peut rester ainsi jusqu'à ce qu'un joueur entre dans ce chunk précis des jours plus tard et tombe à travers le sol, ou que le serveur plante en le chargeant pendant une session totalement différente. L'écart entre la cause et le symptôme explique pourquoi les arrêts forcés sont moins souvent blâmés qu'ils ne le mériteraient : le temps que les dégâts soient visibles, le Kill qui les a causés est oublié depuis longtemps.

Si la console est réellement bloquée

  1. Essayez Stop d'abord et laissez-lui vraiment 60 secondes

    Un serveur sous forte charge — une grosse sauvegarde, un ramasse-miettes, de la génération de chunks — peut prendre plus de temps qu'il n'y paraît. Ce n'est pas la même chose qu'être gelé.

  2. Regardez la sortie console, pas seulement si elle répond aux commandes

    Une sortie qui continue de défiler signifie que le processus est vivant et travaille, même s'il n'accepte pas de commandes à cet instant.

  3. Utilisez Kill seulement ensuite, et sauvegardez dès qu'il est de nouveau en ligne

    Confirmez que le monde se charge encore proprement avant de bâtir quoi que ce soit d'autre sur cette session.

C'est aussi le raisonnement derrière chaque « sauvegardez d'abord » ailleurs dans cette base de connaissances

Un Stop propre est ce que chaque redémarrage programmé, chaque changement de version, chaque réinstallation suppose se produire en dessous. Ce n'est pas une bonne pratique à part — c'est le même mécanisme que décrit tout cet article, tournant simplement automatiquement plutôt qu'à la main.