Programmer des redémarrages automatiques sur un serveur Project Zomboid
Un serveur Project Zomboid laissé allumé plusieurs jours ralentit, même sans lag réseau et même avec assez de RAM. Le serveur tourne sur la JVM Java : la mémoire se fragmente, des entités fantômes s’accumulent, et le TPS se dégrade progressivement. Le redémarrage planifié est la maintenance la plus rentable qui existe sur PZ — quelques secondes d’interruption contre plusieurs heures de fluidité.
Sur un serveur Project Zomboid chez HebergTonServ, les redémarrages se programment directement depuis les tâches planifiées (Schedules) du panel, sans script à écrire.
Pourquoi PZ a besoin de redémarrages
| Phénomène | Conséquence en jeu |
|---|---|
| Fragmentation mémoire de la JVM | RAM consommée qui monte sans jamais redescendre |
| Entités et objets mal libérés | TPS qui baisse, zombies « en retard » |
| Mods Workshop en attente de version | Désynchronisation avec les clients |
| Chunks chargés qui s’accumulent | Sauvegardes de plus en plus lentes |
En pratique, après 6 à 8 heures d’uptime avec une dizaine de joueurs, la consommation mémoire enfle nettement. Un redémarrage vide la JVM et remet le serveur au niveau de performance du premier jour.
La bonne fréquence selon votre serveur
| Profil de serveur | Fréquence conseillée |
|---|---|
| Vanilla, petit groupe (2-6 joueurs) | 1 fois par jour |
| Vanilla ou peu moddé, 10-20 joueurs | Toutes les 8 à 12 h |
| Fortement moddé (40 mods et plus) | Toutes les 4 à 6 h |
| Serveur public 24/7 avec cartes custom | Toutes les 4 à 6 h + un redémarrage complet quotidien |
Choisissez des heures creuses pour vos joueurs : typiquement 5 h et 17 h pour une communauté française.
Redémarrer trop souvent n’est pas anodin non plus : chaque relance rejoue le chargement Workshop et la génération des chunks actifs. En dessous de 3 h d’intervalle, la coupure devient plus coûteuse que le gain.
La séquence correcte : annoncer, sauvegarder, quitter
Ne coupez jamais un serveur PZ sans prévenir. Un joueur en voiture pendant un arrêt brutal se reconnecte souvent sans son véhicule, ou avec une position incohérente.
La séquence à respecter :
servermsg "Redemarrage dans 5 minutes - mettez-vous a l'abri"
servermsg "Redemarrage dans 1 minute - sortez des vehicules"
save
quit| Commande | Rôle |
|---|---|
servermsg "<texte>" | Message diffusé à tous les joueurs connectés |
save | Force l’écriture immédiate du monde sur le disque |
quit | Sauvegarde puis éteint le serveur proprement |
quitsauvegarde déjà, mais lancer unsaveexplicite avant reste la bonne pratique : si lequitse bloque sur un mod récalcitrant, le monde est déjà sur disque.
Liste complète : Commandes admin Project Zomboid
Méthode 1 — Les tâches planifiées du panel (recommandé)
C’est la méthode la plus simple et la plus fiable : le panel exécute des commandes console à l’heure dite, sans machine tierce à maintenir.
- Ouvrez la section Schedules / Tâches planifiées de votre panel
- Créez une tâche Avertissement (ex. tous les jours à 4 h 55) → action Envoyer une commande →
servermsg "Redemarrage dans 5 minutes" - Créez une tâche Sauvegarde à 4 h 59 →
save - Créez une tâche Redémarrage à 5 h 00 → action Redémarrer le serveur
L’expression cron 0 5 * * * correspond à un déclenchement quotidien à 5 h 00. Pour un cycle toutes les 6 heures : 0 */6 * * *.
Avantage décisif : la mise à jour des fichiers serveur et le rechargement des mods Workshop se font au redémarrage. Un redémarrage quotidien maintient donc aussi votre serveur à jour. Voir : Mettre à jour un serveur Project Zomboid
Méthode 2 — Script RCON (auto-hébergement)
En auto-hébergement, un script externe pilote le serveur via RCON. Prérequis : RCON activé dans servertest.ini (RCONPort=27015 et un RCONPassword non vide). Voir : RCON Project Zomboid
Exemple avec mcrcon sur Linux :
#!/bin/bash
HOST="127.0.0.1"
PORT="27015"
PASS="VotreMotDePasseRCON"
mcrcon -H $HOST -P $PORT -p $PASS "servermsg \"Redemarrage dans 5 minutes\""
sleep 240
mcrcon -H $HOST -P $PORT -p $PASS "servermsg \"Redemarrage dans 1 minute - sortez des vehicules\""
sleep 60
mcrcon -H $HOST -P $PORT -p $PASS "save"
sleep 15
mcrcon -H $HOST -P $PORT -p $PASS "quit"À planifier dans crontab (ici tous les jours à 5 h) :
0 5 * * * /chemin/vers/restart-pz.sh >> /var/log/pz-restart.log 2>&1Attention : les commandes envoyées en RCON n’ont pas de slash. En jeu on tape
/save, en RCON c’estsave.
Il faut ensuite un mécanisme qui relance le serveur après l’arrêt : service systemd avec Restart=always, ou boucle dans le script de lancement.
Méthode 3 — Redémarrage manuel bien fait
Si vous préférez garder la main, gardez au moins la discipline :
- Annoncer sur Discord 30 minutes avant
servermsgà 5 minutes, puis à 1 minutesave, attendre quelques secondesquit- Relancer et attendre
SERVER STARTEDavant d’annoncer le retour
Erreurs fréquentes
| Erreur | Conséquence |
|---|---|
Couper le serveur sans save | 10-15 minutes de progression perdues |
| Redémarrer sans annonce | Véhicules perdus, joueurs mécontents |
| Redémarrer toutes les heures | Plus de temps de chargement que de gain |
| Redémarrer aux heures de pointe | Communauté qui se vide |
| Compter sur le redémarrage pour masquer un manque de RAM | Le crash revient toujours |
Ce dernier point est important : si votre serveur ne tient pas 4 heures sans ramer, le redémarrage est un pansement. Le vrai sujet est le dimensionnement — voir Combien de RAM pour un serveur Project Zomboid ?
FAQ
À quelle fréquence redémarrer un serveur Project Zomboid ?
Une fois par jour pour un petit serveur vanilla, toutes les 8 à 12 h à partir d’une dizaine de joueurs, et toutes les 4 à 6 h sur un serveur fortement moddé. Toujours en heures creuses.
Project Zomboid propose-t-il des redémarrages automatiques nativement ?
Non, le serveur dédié n’intègre pas de planificateur. On passe soit par les tâches planifiées du panel de son hébergeur, soit par un script externe en RCON avec cron ou systemd.
Comment prévenir les joueurs avant un redémarrage ?
Avec servermsg "votre message", diffusé à tous les joueurs connectés. Deux annonces suffisent : une à 5 minutes, une à 1 minute, en demandant explicitement de sortir des véhicules.
Un redémarrage peut-il faire perdre la progression ?
Seulement s’il est brutal. Un save suivi d’un quit écrit tout sur le disque avant l’extinction. Un kill direct fait perdre les 10 à 15 dernières minutes de jeu.
Le redémarrage met-il aussi les mods à jour ?
Oui : le serveur recharge les items Workshop au démarrage. C’est pourquoi un redémarrage quotidien réduit fortement les erreurs « file does not match the one on the server » chez les joueurs.
Les redémarrages améliorent-ils vraiment les performances ?
Oui, de façon mesurable sur PZ à cause de la gestion mémoire de la JVM. Un serveur avec 10 joueurs voit sa consommation RAM gonfler sensiblement après 6-8 heures ; le redémarrage la remet à son niveau de départ. Voir : Réduire le lag sur un serveur Project Zomboid
Conclusion
Sur un serveur Project Zomboid, le redémarrage planifié n’est pas une rustine : c’est la contrepartie normale d’un moteur Java qui accumule de la mémoire. Annoncez avec servermsg, sauvegardez avec save, éteignez avec quit, et calez la fréquence sur votre charge — quotidien en vanilla, toutes les 4 à 6 heures en fortement moddé.
Pour un hébergeur Project Zomboid avec tâches planifiées intégrées, console en temps réel et sauvegardes automatiques, HebergTonServ démarre à 25,90 €/mois.
Pour aller plus loin
- RCON Project Zomboid : activer et administrer à distance
- Commandes admin Project Zomboid : la liste complète
- Réduire le lag sur un serveur Project Zomboid
- Sauvegarder et restaurer un serveur Project Zomboid
- Sauvegardes automatiques : BackupsPeriod et SaveWorldEveryMinutes
- Hébergeur Project Zomboid dès 25,90€/mois
