Le code de sortie n'est pas une raison de crash, c'est un haussement d'épaules
Le nombre ne vous dit rien. La ligne au-dessus vous dit tout, et elle se trouve déjà dans votre dossier de logs.
Un serveur Java qui meurt affiche Exit Code 1 et s'arrête. C'est tout le message. Le code de sortie 1 signifie « le processus s'est terminé anormalement » — c'est une catégorie, pas une cause, et elle couvre aussi bien un dossier de monde manquant qu'un mod qui plante pendant le chargement des classes.
Où se trouve la vraie réponse
Le code de sortie est la dernière ligne de logs/latest.log. La cause se trouve dans les lignes qui précèdent. Remontez depuis la fin jusqu'à tomber sur le premier Exception, Caused by: ou Failed to. Cette ligne nomme la classe, le mod ou le fichier.
[Server thread/ERROR]: Encountered an unexpected exception
java.lang.NoSuchMethodError: net.minecraft.world.level.Level.getBiome
at com.example.mod.ExampleMixin.inject(ExampleMixin.java:41)
Caused by: java.lang.NoClassDefFoundError: com/example/lib/HelperIci, NoClassDefFoundError correspond à une dépendance manquante, pas à un monde corrompu. Le code de sortie ne vous a rien dit de tout cela.
Les codes de sortie que vous verrez vraiment
| Code | Signification habituelle |
|---|---|
| 0 | Arrêt propre — /stop ou un redémarrage planifié |
| 1 | Exception non gérée, ou le JVM a refusé de démarrer |
| 137 | Tué par le système d'exploitation, presque toujours par l'OOM killer |
| 143 | SIGTERM — un orchestrateur de conteneurs l'a arrêté |
Le code 137 est celui que les gens confondent avec un crash. Le JVM n'a pas échoué ; quelque chose à l'extérieur a décidé que le processus avait utilisé trop de mémoire.
Java et Bedrock ne posent pas le même problème
Le serveur Bedrock écrit bedrock_server.log et n'émet pas du tout de code de sortie à la manière de Java — il génère un rapport de crash handler avec une pile d'appels et une ligne Crash report. Les conseils écrits pour les logs Java ne s'y appliquent pas.
Les piles moddées échouent différemment
Avec des mods, la première exception est souvent un symptôme. Un mixin qui échoue à s'appliquer produit une cascade où le vrai coupable est la première ligne Mixin apply failed, pas la ligne NoSuchMethodError trente lignes plus loin. Cherchez Mixin dans le log avant de chercher Exception.
Vérifier si le serveur est en ligne
Un log vous dit pourquoi il est mort. Il ne vous dit pas s'il est vivant maintenant. Une vérification TCP sur le port du serveur répond à cette question en une seule requête, et elle fonctionne de la même manière pour Java et Bedrock puisque les deux communiquent via une socket.
Collez le log dans l'outil Server Diagnostics pour en extraire la ligne fautive, et indiquez-y votre hôte pour confirmer que le serveur répond réellement.