9 août 2023
Suite à un brutal PWR ON Reset imposé par l’hébergeur,
WordPress ne fonctionne plus correctement.
L’heure système est correcte mais l’heure WP est différente, près de 1 an de retard.
Heure System dans le cartouche bas sous “Fichiers” : OK
Heure WP dans le cartouche bas @ “Heure actuelle” : BUG
Ce décalage se retrouve dans tous les sites mutualisés sur ce serveur.
La capture d’écran ci-dessous montre deux aspects du BUG (SysTime).
- Dans le cartouche haut une erreur SSL qui bloque les accès aux serveurs WP pour les MàJ.
Or les certificats sont à jour, les accès https:// sont reconnus et validés. - Le bug se situe dans le cartouche bas, la date WordPress diffère de celle du système.
WP a une année de retard, ceci explique les soucis du cartouche supérieur.
Comment ajuster la date WP à celle du système ?
====================================================================
12 août 2023
La capture d’écran montre une divergence entre l’heure UTC ajustée à l’heure légale.
J’ai donc recherché comment l’heure PHP de WP pouvait être à nouveau cohérente avec l’heure réelle.
Les recherches dans les fonctions PHP sont restées vaines jusqu’au moment de l’EUREKA.
J’ai passé les commandes suivantes :
================================= Début session interactive
jlc@sd-97059:/var/www/site-cech$ date
Mon 12 Sep 2022 04:09:26 AM CEST
jlc@sd-97059:/var/www/site-cech$ php -a
Interactive mode enabled
php > echo date(‘Format String’, time());
September2022Mon, 12 Sep 2022 04:09:51 +020009am30 th30Mon, 12 Sep 2022 04:09:51 +02000994
php > quit
jlc@sd-97059:/var/www/site-cech$ date
Mon 12 Sep 2022 04:09:57 AM CEST
jlc@sd-97059:/var/www/site-cech$ timedatectl
Local time: Mon 2022-09-12 04:12:18 CEST
Universal time: Mon 2022-09-12 02:12:18 UTC
RTC time: Mon 2022-09-12 02:12:18
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: n/a
RTC in local TZ: no
================================= Fin session interactive
On constate qu’à la différence de la capture d’écran,
l’heure système et l’heure PHP sont identiques.
Donc l’heure système est incorrecte.
C’est en fait l’heure à laquelle j’avais installé le système il y a près d’un an.
Depuis, je n’étais jamais intervenu ni avait relancé le serveur.
Or tel qu’installé, la fonction NTP (Network Time Protocol) n’était pas active.
En fait NTP n’était pas installé. Problème résolu en passanr la commande suivante :
jlc@sd-97059:/var/www/site-cech$ sudo apt install chrony
On vérifie que désormais l’heure est correcte :
jlc@sd-97059:/var/www/site-cech$ date
Fri 11 Aug 2023 10:21:09 AM CEST
Sauvé, l’heure système, l’heure réelle et l’heure WordPress sont identiques.
Les fonctions de MàJ des extensions et noyaux WP sont désormais actives.
================================== Question en suspend
Dans le cartouche de la capture d’écran de l’extension UPDRAFT la date est correcte
alors que j’ai montré que la date système est erronée, voir la session interactive.
Cette divergence entre les deux dates, celle du système et la réelle, introduit
une difficulté d’interprétation de la cause.
Heureusement la session interactive aura permis de pointer le problème
et apporter une solution pérenne.
Pourquoi UPDRAFT se sert-il de la date réelle et non celle du système ?
================================== Causes et résolution
Afin de changer le routeur fautif, Online.net a coupé l’alimentation de la baie sans passer par les procédures d’arrêts propres. De fait, l’administration du Data Center ne disposait pas des couples ID/PWD pour lancer un arrêt programmé. Le serveur a donc subit un arrêt brutal. De mon côté, je ne pouvais pas non plus arrêter le serveur, le routeur étant en panne, l’accès à la console système était fermé.
Lors de la remise en marche, le serveur a repris la date initiale de lancement, il y a près d’un an.
En fait, l’installation telle que paramétrée par Online.net ne prévoyait pas ce type d’arrêt brutal.
La solution à ce problème passe par l’installation d’une interface au service NTP.
Idéalement, l’image installée du noyau UBUNTU devrait comprendre
le daemon chrony