20 novembre 2023
- Impossible de paramétrer Thunderbird pour un serveur Postfix / Dovecot
Un souci de fermeture dans la fin des sauvegardes par UPDRAFT crée un message d’erreur.
Un signe de ce souci était une différence de date d’exécution des sauvegardes des bases de données et les fichiers.
En changeant la fréquence des Backups, la date de lancement de sauvegarde des fichiers et bases de données est correcte, mais le lancement automatique ne se produit pas.
En cliquant sur « Sauvegarder », le Backup se déroule OK, je reçois un courriel de bonne exécution de la sauvegarde.
Des causes possibles de non lancement sont listées ci-dessous.
Maintenance mode : le site n’est pas en mode maintenance
No visitors : le site est visité
Disabled schedulers : Pas trouvé le moyen de tester
Loopback connections are not working : Les loopback fonctionnent
External cron jobs : Pas de cron jobs running
Password protected websites : Pas de protection de site par PW
Installer l’extension WP_Control qui informe sur WP-Cron
Le problème semble lié à curl et si curl est ok depuis un client distant,
en interne une erreur est générée.
jlc@sd-97059:~$ curl https://depancech.com
curl: (7) Failed to connect to depancech.com port 443: Connection refused
La commande curl avec le flag -k qui force l’acceptation de la commande,
la commande génère aussi une erreur.
jlc@sd-97059:~$ curl -k https://depancech.com
curl: (7) Failed to connect to depancech.com port 443: Connection refused
inséré à la fin de /var/www/site-n/wp-config.php les deux lignes suivantes :
# Traiter WP_CRON défectueux
define(‘ALTERNATE_WP_CRON’, true);
define(‘DISABLE_WP_CRON’, false);
Cette modification ne concerne qu’un seul des quatre sites hébergés et n’a rien changé dans le comportement de WP CRON des quatre sites.
Exécuté un clean « reboot » via ssh :
MIRACLE ! Tout refonctionne !
S les sauvegardes en attente sont reparties automatiquement pour les quatre sites,
ce bonheur n’a pas duré, après quelques minutes, le CRON de WP s’est à nouveau bloqué.
Régler ce problème qui impacte tous les sites du serveur mutualisé impose une connaissance fine des interfaces entre WP / Apache / Linux. Et là, c’est trop demander.
Or les sauvegardes manuelles fonctionnent. Donc le problème est dans les couches inférieures.
Dans un terminal, la commande date confirme que l’heure système retarde de 9 mois.
J’ai installé un DAEMON qui synchronise l’heure système via ntp
– Dès l’nstallation l’heure système est enfin correcte.
– Après un reboot, elle est toujours correcte. Le problème semble réglé.
L’arrêt « sauvage » de la baie pour remplacer le Switch défaillant aura tué les mécanismes de l’heure système. Il semble que ce soit l’unique fonction qui aura été affectée.
C’est la deuxième fois que la maintenance des Data Centers de Online.net plantent mes serveurs.
Il semble que les deux plantages soient liés à des arrêts « Brutaux ».
Pourquoi Online.net ne met pas en place une solution
pour lancer un arrêt propre « Off Line » lorsque le client n’a plus accès à sa machine ?
Insérer la vidéo Farce de Bouc