Le site a bien été mis à jour rapidement après l’annonce de la version 4.3.2 ? As-tu demandé à ton hébergeur d’analyser le contenu afin de vérifier qu’il n’a pas été piraté ?
« Je ne vois pas le rapport avec la réponse.
Votre site génère des process en boucle, un spameur est effectivement un souci au niveau du site, cependant, cela ne corrige en rien votre saturation de process. »
a ce stade là, j’aurais tendance à soupconné que le site a été l’objet d’un piratage à un moment avec un malware en arrière plan. Autrement dit ce ne serait pas SPIP en lui meme qui fait tourner le process, mais plutot un truc derrier
Sauvegarde de la BASE, du dossier IMG et du dossier plugins
Effacement de tout SPIP
Reinstallation
Laisser pendant quelques temps voir si cela sature encore.
Si pas le cas, finir la reinstallation
a. Reimport de la base
b. Reimport du dossier IMG par étape en n’y mettabt que les fichiers legitimes
c. Reinstallation des plugins depuis l’espace de SPIP
Pour vous cet identifiant signifie quelque chose ? c’est votre identifiant O2Switch ? (ça ressemble à un identifiant O2S)
Cette IP 167.71.55.227 (Digital Ocean Francfort) semble pas très clean non plus bien que dans votre cas on dirait que c’est elle la cible, je pencherai aussi pour un site piraté avec un malware qui tente d’établir une connexion à 167.71.55.227, cette IP étant signalée comme abusive, il n’est pas impossible que le malware tente une connexion avec une IP qui a entre temps été nettoyée, d’ou les échecs.
ChapGPT:
Ces appels systèmes montrent qu’un programme tente de se connecter à un serveur via une socket TCP/IP à l’adresse 167.71.55.227 sur le port 6667, mais la connexion est refusée. Ensuite, plusieurs tentatives d’opérations qui sont inappropriées pour une socket (comme ioctl et lseek) échouent logiquement.
Le fait que votre site fasse ce genre de tentative de connexion vers l’extérieur semble indiquer qu’il y a un programme qui essaye de faire ça et je ne pense pas que ce soit Spip …
Et l’analyse par ChaptGPT du log Spip est intéressante, vu qu’il ne sait pas que c’est Spip … je me demande s’il a tout juste, la conclusion donne des pistes mais je ne sais pas si ces erreurs Spip ont à voir avec les process évoqués par O2S, par essence le log Spip ne voit que ses propres erreurs et problèmes:
Ce journal semble provenir d’un serveur ou d’une application web (peut-être sous un système CMS comme SPIP, vu la structure des erreurs et des chemins de cache). Voici une analyse détaillée de chaque ligne :
2024-09-09 21:40:44 104.168.171.139 (pid 1839742) :Pub:!INFO: form ecrire_auteur:email_nobot rempli: sonic@busihelp.xyz
Un utilisateur (probablement avec l’adresse IP 104.168.171.139) a rempli un formulaire (potentiellement un formulaire de contact ou d’inscription) où le champ d’email sonic@busihelp.xyz a été utilisé. Le préfixe email_nobot pourrait indiquer une protection anti-bot (comme un captcha).
Une erreur survient lors de la création du répertoire tmp/cache/calcul/60/, nécessaire pour le système de cache. L’adresse IP associée à cette action est 35.91.190.215. Cela pourrait être causé par des permissions incorrectes sur le dossier ou un problème de capacité du serveur.
2024-09-09 23:14:55 109.234.160.100 (pid 2082817) :Pub:!INFO: Collision avec le paquet <spip-contrib-extensions/territoires_stat-c5e87-territoires_stat-1.1.0.zip / Connexion · GitLab 1> du depot <11>
Un message d’information indique une collision avec un paquet lors d’une tentative de gestion de l’extension territoires_stat (probablement une extension SPIP). La collision pourrait signifier que plusieurs processus essaient de manipuler ce fichier simultanément, ou qu’il y a un conflit de version dans le dépôt GitLab.
Nouvelle erreur liée à la création d’un dossier cache, ici tmp/cache/calcul/b5/, associée à l’adresse IP 20.120.134.35. Cela peut aussi être un problème de droits ou de disponibilité du stockage.
2024-09-10 02:38:10 104.248.83.242 (pid 2752540) :Pub:ERREUR: queue_close_job car _JQ_PENDING depuis +180s : Array
Ce message d’erreur signale un problème avec une file d’attente de tâches (queue_close_job) qui n’a pas été traitée depuis plus de 180 secondes. Cela pourrait indiquer un blocage dans l’exécution d’une tâche ou un problème de gestion des files d’attente.
Résumé :
Le journal montre des problèmes récurrents avec la création de répertoires de cache, probablement dus à des permissions incorrectes, un manque de place ou des problèmes de configuration du serveur. Il y a aussi un conflit lié à une extension SPIP, ainsi qu’un souci avec la file d’attente de tâches. Il serait recommandé de vérifier les droits d’accès aux dossiers de cache et la configuration des extensions.
