Orbiter — Erreurs connues et solutions

Erreurs d'installation

Erreur : « Run via SSH: php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php » Le script de post-installation n'a pas pu s'exécuter automatiquement. Connectez-vous en SSH en tant que root et lancez la commande manuellement :

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Erreur : « install-deps failed » L'installation des dépendances système a échoué. Exécutez en tant que root :

bash /opt/psa/admin/plib/modules/orbiter/scripts/install-all.sh

Vérifiez que le serveur dispose d'un accès Internet et que le gestionnaire de paquets (apt/yum) fonctionne normalement.

Erreur : « Dockerfile not found » Les fichiers de construction Docker n'ont pas été copiés correctement lors de l'installation. Relancez la post-installation ou réinstallez l'extension depuis le gestionnaire d'extensions de Plesk.

Erreur : « Default nginx template not found » Le modèle de proxy Nginx est manquant. Relancez :

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Erreurs de construction de l'image Docker

La construction a échoué / « Build failed » dans l'interface Consultez les journaux de construction affichés sous la barre de progression. Causes fréquentes :

• Aucun accès Internet pour télécharger les images de base
• Espace disque insuffisant (minimum 20 Go recommandés)
• Le démon Docker ne tourne pas : systemctl start docker

« docker run failed » / Le conteneur ne démarre pas Vérifiez que :

1. Docker fonctionne : systemctl status docker
2. Suffisamment de RAM est disponible (minimum 2 Go au total)
3. Aucun conflit de port : recherchez port already in use dans les journaux

« Web volume mount failed. Check that the path exists » Le chemin du document root du domaine n'existe pas ou est inaccessible. Vérifiez dans Plesk que le chemin de fichiers du domaine est correct et que le répertoire existe sur le disque.

Erreurs de création de conteneur

« Error creating » / Conteneur bloqué à l'état « creating » Une opération de création précédente a peut-être laissé un fichier de verrou. Vérifiez :

ls /opt/psa/var/modules/orbiter/locks/

Si un fichier .lock existe pour le domaine et qu'aucune opération n'est en cours, supprimez-le :

rm /opt/psa/var/modules/orbiter/locks/<domain>.lock

« Container is delete-locked. Unlock it first, or use force=1 » Le conteneur a le verrou anti-suppression activé. Rendez-vous dans la section Conteneur du panneau d'actions, basculez le verrou sur Déverrouillé, puis réessayez l'opération.

« Failed to apply network limit » La limite réseau de Docker n'a pas pu être appliquée. C'est généralement non critique — le conteneur fonctionne, mais sans limitation de débit réseau. Vérifiez la compatibilité de la version de Docker.

« Quota exceeded » Le client Plesk a atteint son quota de conteneurs, de RAM ou de bases de données défini par l'administrateur. Contactez l'administrateur du serveur pour augmenter le quota, ou supprimez d'abord un conteneur existant.

« Failed to enable nginx PHP mode » Nginx n'a pas pu être configuré pour relayer les requêtes PHP vers le conteneur. Exécutez :

plesk repair web -y

Erreurs MariaDB

« MariaDB is starting, please wait a few seconds... » MariaDB s'initialise encore à l'intérieur du conteneur. Attendez 10 à 15 secondes puis rafraîchissez. Si cela persiste au-delà de 60 secondes, redémarrez le conteneur.

« Dump failed. Check that MariaDB is running » MariaDB ne tourne pas à l'intérieur du conteneur. Rendez-vous dans le panneau Base de données et cliquez sur « Démarrer MariaDB », ou redémarrez le conteneur complet. Si l'échec apparaît de façon récurrente dans le journal de la sauvegarde nocturne (/opt/psa/var/modules/orbiter/logs/orbiter.log avec [Cron] FAIL ALL: Dump failed), le service MariaDB à l'intérieur du conteneur est probablement bloqué à l'état FATAL. Vérifiez-le avec :

docker exec php-fpm-<domain> supervisorctl status mariadb

S'il indique FATAL Exited too quickly, voyez État FATAL de MariaDB (Can't initialize timers) ci-dessous.

État FATAL de MariaDB (Can't initialize timers) — PidsLimit trop bas MariaDB a besoin de plusieurs threads internes (timers, gestionnaires de signaux, workers InnoDB) pour démarrer. Si le pids.max du cgroup du conteneur est inférieur à ce que MariaDB requiert, mariadbd s'interrompt immédiatement au démarrage avec :

Can't initialize timers
[ERROR] Aborting

Supervisord réessaie 3 fois puis marque le service comme FATAL. Le conteneur reste actif — seul le MariaDB qu'il contient est mort — et les sauvegardes nocturnes échouent silencieusement chaque nuit.

Comment détecter. Inspectez les limites du conteneur :

docker inspect php-fpm-<domain> --format '{{.HostConfig.PidsLimit}}'

S'il renvoie 100 ou moins et que le conteneur a MariaDB activé, vous avez trouvé la cause.

Comment corriger. Augmentez la limite du cgroup à chaud (pas besoin de recréation) et redémarrez le service :

docker update --pids-limit=512 php-fpm-<domain>
docker exec php-fpm-<domain> supervisorctl restart mariadb

Vérifiez ensuite : docker exec php-fpm-<domain> supervisorctl status mariadb doit désormais indiquer RUNNING. La sauvegarde nocturne reprendra d'elle-même.

Prévention. Orbiter applique un minimum MariaDB de 150 PID lorsque le moteur est activé au moment de la création du conteneur, mais un conteneur créé avant cette protection (ou un conteneur dont la limite a été abaissée manuellement via la fenêtre Limites) peut se retrouver sous le seuil. Après une activation + MariaDB, vérifiez que la limite de PID du conteneur n'est pas un reliquat d'un préréglage Conservateur. Depuis l'interface, la fenêtre Limites grise désormais les valeurs de PID inférieures à 150 lorsque MariaDB est présent sur le même site.

MariaDB plante immédiatement après le démarrage du conteneur (erreur io_uring) Cela affecte les hôtes où io_uring_disabled=2 ou où libaio est indisponible. Le correctif est appliqué automatiquement depuis Orbiter 1.5.4. Si vous êtes sur une version plus ancienne, exécutez :

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Cela propage la configuration innodb_use_native_aio=0 à tous les conteneurs MariaDB en cours d'exécution.

« MySQL error » lors de la création d'un utilisateur / d'un grant Le mot de passe root de MariaDB a peut-être changé ou le conteneur a besoin d'un redémarrage. Essayez de redémarrer MariaDB depuis le panneau Base de données, puis réessayez l'opération.

phpMyAdmin « Failed to set session cookie » Cela se produit après une migration de slug phpMyAdmin où le vhost nginx et le config.inc.php dans le conteneur sont désynchronisés. Corrigé dans Orbiter 1.5.3. Mettez à jour vers la dernière version, ou recréez le conteneur.

L'import de base de données échoue avec une erreur de syntaxe Le fichier SQL importé contient peut-être des instructions de niveau système qui ont été filtrées. Orbiter retire automatiquement les instructions dangereuses. Si l'import échoue entièrement, vérifiez que le fichier est bien du SQL valide (et non un fichier texte d'une seule ligne) et qu'il n'est pas corrompu.

Erreurs Nginx / serveur web

« Failed to write proxy configuration » Orbiter n'a pas pu écrire la configuration de proxy Nginx pour le domaine. Vérifiez l'espace disque et les permissions sur /etc/nginx/. Lancez plesk repair web -y pour réinitialiser la configuration nginx.

Le site renvoie un 502 Bad Gateway après la création du conteneur Le conteneur est peut-être encore en cours de démarrage. Attendez 10 à 15 secondes puis rafraîchissez. Si cela persiste :

1. Vérifiez que le conteneur fonctionne dans Orbiter
2. Consultez les journaux du conteneur pour des erreurs de démarrage de PHP-FPM
3. Essayez de redémarrer le conteneur

Le site renvoie un 403 Forbidden sur les fichiers PHP avec Shield activé C'est le fonctionnement normal de Shield. Shield bloque l'exécution des fichiers PHP dans les répertoires en lecture seule. Si un fichier PHP légitime est bloqué, vous pouvez :

• Ajouter son répertoire parent à la liste des répertoires accessibles en écriture dans les réglages de Shield
• Ou désactiver temporairement Shield pour tester

« Container is not starting correctly. Logs: » suivi d'une sortie d'erreur Lisez les journaux affichés dans l'erreur. Causes fréquentes :

• Erreur de configuration de PHP-FPM (vérifiez les erreurs de syntaxe dans le php.ini personnalisé)
• Conflit de port (un autre processus utilise le port attribué)
• Mémoire insuffisante

Erreurs de cache

La purge du cache renvoie « Permission denied » Nginx crée les sous-répertoires de cache en mode 700. Orbiter applique automatiquement chmod -R 777 sur ces sous-répertoires depuis la version 1.5.0. Si vous rencontrez cette erreur sur une version plus ancienne, mettez Orbiter à jour ou exécutez :

chmod -R 777 /var/cache/orbiter/<domain>/

« Error during flush » Le cache Nginx n'a pas pu être vidé. Vérifiez que le répertoire de cache existe et est accessible. Essayez de purger depuis le panneau Cache de l'interface Orbiter.

Erreurs de la CLI

--version indique une version erronée Corrigé dans Orbiter 1.5.2. Mettez à jour vers la dernière version. La CLI lit désormais meta.xml dynamiquement.

--db-export > dump.sql produit un fichier texte d'une seule ligne Corrigé dans Orbiter 1.5.2. Le dump SQL est désormais envoyé sur stdout et le message de statut sur stderr. Mettez à jour vers la dernière version.

WARNING: Error loading config file: open /root/.docker/config.json: permission denied Cet avertissement apparaissait sur chaque commande docker dans les versions antérieures à 1.5.2. Il est cosmétique et n'affecte pas le fonctionnement. Corrigé dans Orbiter 1.5.2 en définissant DOCKER_CONFIG=/nonexistent.

Erreurs de synchronisation / sauvegarde

« Sync failed » / « Connection failed » Pour les destinations de sauvegarde externes (S3, SFTP, FTPS) :

1. Vérifiez les identifiants dans la configuration de la destination de sauvegarde
2. Utilisez le bouton « Tester la connexion » pour diagnostiquer
3. Vérifiez que le serveur peut joindre l'hôte distant (pare-feu, DNS)

« Cannot read inventory file » Le fichier de configuration de la destination de synchronisation est manquant ou corrompu. Supprimez la destination et ré-ajoutez-la depuis le panneau Réglages → Sauvegardes.

La sauvegarde nocturne signale de façon répétée FAIL ALL: Dump failed pour un domaine Le service MariaDB à l'intérieur de ce conteneur est bloqué à l'état FATAL. Voyez État FATAL de MariaDB (Can't initialize timers) dans la section Erreurs MariaDB ci-dessus pour le diagnostic et la correction.

Erreurs générales

« sysop returned invalid JSON » Erreur de communication interne entre le code PHP d'Orbiter et le binaire privilégié sysop. Généralement transitoire. Réessayez l'opération. Si elle persiste, consultez /var/lib/orbiter/orbiter.log pour plus de détails.

« ConfigStore init failed, falling back to JSON » La base de configuration SQLite n'a pas pu être ouverte. Orbiter bascule automatiquement sur un stockage JSON, de sorte que le fonctionnement est préservé. Vérifiez l'espace disque dans /var/lib/orbiter/.

« Unknown error » sur n'importe quelle opération Consultez le fichier journal d'Orbiter pour plus de détails :

tail -100 /var/lib/orbiter/orbiter.log

Vérifiez aussi le journal d'erreurs de Plesk :

tail -100 /var/log/plesk/panel.log