Aller au contenu

mdata

Membres
  • Compteur de contenus

    135
  • Inscription

  • Dernière visite

  • Jours gagnés

    12

Tout ce qui a été posté par mdata

  1. De mon côté c'est toujours down pour moi. Des avancées depuis l'intervention sur le stockage ?
  2. Mes observations à présent : - Les sites sont toujours down, on n'est plus au stade de l'erreur de connexion aux DB mais toujours en pédalage débouchant sur du 504 (gateway time out) - Les serveurs DB sont par contre visiblement up, je me connecte sans problème à mysql7 depuis phpmyadmin - Roundcube a un fonctionnement très aléatoire, avec des fois des messages d'erreur sur le stockage (ce qui est une fausse piste, c'est le message d'erreur par défaut de roundcube) Je ne connais pas l'architecture de la plateforme yulpa, mais de ce que j'en vois je me permets de supposer que le souci n'est pas sur les DB elles-mêmes (vu qu'elles répondent) mais peut être sur les connecteurs situés au niveau des services web. Au boulot, nous avons eu des sketches de ce genre avec des dockers php et mysql qui perdaient leur connexion et la seule solution était de relancer toute l'infra docker pour que ça veuille bien fonctionner. Nous avons eu aussi des blagues avec SSSD qui se mettait à consommer de la RAM à outrance et du coup bloquait les services. Autre piste sinon, peut être un souci réseau entre la couche web et le stockage ? Après comme je disais je ne connais pas votre infra et peut être que les symptômes qu'on pense déceler du dehors sont à côté de la plaque. Ah sinon il y a aussi d'énormes latences sur le forum !
  3. Je suppose qu'il y a eu du reboot dans l'air du côté des serveurs mysql, le 3 (roundcube) est revenu, le 7 (où sont mes sites) pas encore... Du côté de phpmyadmin : mysqli::real_connect(): (HY000/2002): Connection refused La connexion au « controluser » telle que définie dans la configuration a échoué. mysqli::real_connect(): (HY000/2002): Connection refused
  4. Nouvel épisode du feuilleton, qui semble bien confirmer la piste mysql : Je tente désespérément de répondre à un mail depuis le roundcube de yulpa et il ne fonctionne plus en se plaignant du serveur mysql3 (ah bin le temps de taper ce message le service a complètement implosé)
  5. Toujours pas d'idée d'un redémarrage du service ?
  6. Pour préciser encore davantage : - Les sites en panne : wtcomics.fr et test.wtcomics.fr (Wordpress les 2) - Le site qui marche : img.wtcomics.fr (php maison qui utilise des données en flat text et sert les images)
  7. Clairement ! On est toujours sur le délicat dossier de la migration 7->10 au boulot et c'est loin d'être gagné...
  8. Je pense que la version de SQL ne doit pas forcément jouer, mes deux sites sont sur des Maria 10.3 et ils sont touchés aussi. Par contre je constate toujours que mon site en php simple/flat text (donc pas de db) n'est pas tout tout impacté et fonctionne normalement (manque de bol c'est un serveur interne donc pas utile pour les visiteurs)
  9. J'entends bien, mais nous on fait quoi en attendant ? Et question subsidiaire : une idée du retour à la normale sur la panne en cours ?
  10. Pareil, mon SEO est très affecté et mes soucis récurrent amusent beaucoup mes petits camarades de jeu dans mon secteur d'activité (sans compter que ça devient compliqué de convaincre les partenaires du sérieux du site s'il est en panne la moitié du temps)
  11. Ouais bin à un moment si moi je m'en vais je ne reviendrai pas ! 😡
  12. Mes sites sont down aussi ce matin, à l'exception de celui qui n'utilise pas de base de données. Ca devient pénible là...
  13. En tout cas ce soir c'est à nouveau down
  14. Oui et non... certes, en mutualisé on est tributaires de ce qui passe avec les autres sites mais la plateforme n'était pas aussi instable par le passé.
  15. Ca c'est clair et c'est tellement dommage
  16. Malheureusement on n'en sait pas plus pour le moment
  17. On va croiser les doigts, mais en tout cas pour le moment le service semble reparti.
  18. Je partage ce sentiment, je suis sur Yulpa depuis les temps anciens de Web4All et j'étais très content du service et de la qualité de fonctionnement de la plate-forme. Là ça va de mal en pis, ça devient très compliqué de travailler et de bâtir une réputation pour mon site s'il a ses vapeurs tous les 4 matins.
  19. Je confirme le côté insupportable.
  20. Même constat : l'entrée dans "travaux" ouverte quand j'ai fait beaucoup de bruit un peu partout (y compris sur les réseaux sociaux) jamais mise à jour, une panne répétitive sans aucun retour à part le laconique message de la dernière fois lorsqu'on a râlé... J'en ai vraiment marre !
  21. Et on est repartis ce matin pour une nouvelle salve de 507 ou de timeout...
  22. Entre temps yulpa a répondu sur Twitter et a ajouté une tâche sur le panneau de travaux.
  23. En tout cas environ huit heures de panne / fonctionnement très dégradé, absolument aucun retour et on ne sait même pas si quelqu'un travaille ou non sur la panne. La déception est immense.
  24. Pareil, j'alterne les erreurs et en tout cas je ne peux pas travailler. Je suis très content de bloquer du temps pour bosser sur mon site et au final je ne peux rien faire. Très content aussi de voir ricaner les concurrents bien contents de voir mon site par terre. Clairement ça me fait vraiment mal au coeur de dire ça en tant que client de très longue date, mais je commence à regarder de façon plus soutenue ce qui se fait ailleurs et le renouvellement n'est clairement pas gagné. Je veux bien être plein de bonne volonté et de compréhension mais à un moment un site en panne de façon répétée ce n'est pas viable. Et j'en profite pour préciser que ça ne m'amuse pas du tout de jouer au client grincheux, d'autant que je sais très bien que c'est un métier compliqué.
  25. Oui j'en ai parlé sur un autre topic, c'est la fête ce matin Je suppose (mais c'est une supposition) que c'est lié aux bases de données car un de mes sites qui n'en utilise pas n'a aucun souci.
×
×
  • Créer...