Le serveur d’un de nos serveur (mutu3) a saturé sur le nombre des accès (le nombre de fois par seconde pendant lesquels les fichiers sont consultés ou écrits).
Les Nextclouds sur ce serveur étaient injoignable entre 15h et 21h ce vendredi 5 septembre 2025.
Nous allons prendre les mesures nécessaire pour que cela n’arrive plus (séparation/isolation des services sur plusieurs serveurs).
Vous avez été plusieurs à nous signaler des Nextcloud indisponibles ce matin. La coupure a eu lieu entre 3h du matin et 13h30 aujourd’hui 25 août 2025.
Le problème était du à une surcharge d’un de nos serveur mutualisé. La surcharge a été générée par des taches de fond qui mettaient trop de temps à s’exécuter, et qui du coup s’empilaient les unes sur les autres et accentuaient le ralentissement.
Nous avons mis en place un mécanisme afin que cela ne se reproduise plus.
Pour une raison non encore identifiée (mais qui semble concomitante avec des soucis de notre hébergeur OVH), notre passerelle de sortie mail a été hors ligne de hier soir (31/07/2025 23h30) jusqu’à aujourd’hui midi (1/08/2025 12h00).
Le serveur semble avoir redémarré hier soir. Pour des raisons de sécurité, après chaque redémarrage, nos serveurs nécessitent une intervention manuelle, qui est arrivée aujourd’hui en fin de matinée.
Les conséquences sont :
Les mails envoyés vers des destinataires externes entre hier 23h30 et aujourd’hui 12h00 sont restés dans une file d’attente. Ils sont tous partis à midi aujourd’hui
Ce souci concerne aussi les notifications de services (Mattermost, Nextcloud)
L’envoi de mails vers des destinataires internes (dont les boites mail sont hébergées chez le Cloud Girofle) n’a pas été affectée
La réception de mails n’a pas été affectée
Aucun mail n’a été perdu a priori
Une soixantaine de mails sont concernés par cet incident
Nous sommes vraiment désolé de ce souci, qui a généré 12h30 d’interruption d’emails. C’est l’été ⛱️.
Bonjour bonjour, en cette belle journée de ce samedi après-midi, alors qu’on était tranquillement en train de profiter du mois de juin, un de nos serveurs a décidé qu’il était plein, plus d’espace disque dispo pu rien.
Alors ça a ralenti tout le monde jusqu’à ce qu’on vienne prendre un peu soin de lui.
Tout est rentré dans l’ordre, le souci a duré en gros de 18h30 aujourd’hui jusqu’à 19h.
Cette semaine, le lundi 03/02/2025 et mercredi 05/02/2025, nous avons eu des coupures de mails.
Lundi entre 14h10 et 15h00, et mercredi entre 14h30 et 15h40. Les mails envoyés sur cette période sont bien partis, et les mails reçus sont arrivés avec un peu de retard.
Cela est dû à une augmentation soudaine de l’utilisation des processeurs sur notre serveur, mais nous n’avons toujours pas trouvé la cause du problème.
Aujourd’hui (30/01/2025), nous avons eu une coupure de mails, entre 9h15 et 10h15. Les mails envoyés sur cette période sont bien partis, et les mails reçus devraient arriver aujourd’hui au plus tard.
Depuis un mois, l’équipe du Cloud Girofle réalise une transition de serveur de mail : nous reconfigurons tous les services qui envoient des mails, et mettons en place une nouvelle porte de sortie. Cela nécessite de reparamétrer des dizaines de services et de logiciels.
Dans cette opération, à deux reprises, le 23/12 et le 27/12, nous avons fait une erreur de configuration, et pendant quelques heures, l’envoi d’emails ne fonctionnait pas. Chaque mail recevait un message d’erreur :
Nous avons corrigé le souci. Les messages qui ont reçu cette erreur n’ont pas été envoyés, vous devez les renvoyer.
[Ajout du 4/01/2025] Dans l’opération, nous avons fait une erreur de configuration du serveur qui héberge les forums Discourse et Mattermost : les notifications par mail n’ont pas été envoyées pendant plusieurs jours (entre le 24/12 et le 3/01, dix jours)
Le 9 et 10 juillet derniers, nous avons souffert de 2 pannes consécutives du service mail. Le 9/07 le service a été ininterrompu pendant 4h, et le 10/07 pendant 1h.
Dans les deux cas, nous avons constaté une hausse soudaine de l’usage du CPU. Le 09/07, la charge CPU a baissé au bout d’une heure, mais le service n’est revenu que lorsque nous sommes intervenus. Le 10/07 nous sommes intervenu plus rapidement mais le problème était le même.
Après recherche dans les journaux d’erreurs (merci à Korsani et Max), nous avons pu trouver une corrélation entre des erreurs de DNS et les montées en charge. Nous en avons conclu qu’une indisponibilité des DNS que nous utilisons provoquait en chaîne des erreurs sur les conteneurs Mailcow.
Nous avons donc changé les DNS que nous utilisons afin que cela ne se reproduise plus, et nous avons mis en place un planning d’astreinte afin de s’assurer d’avoir au moins une personne présente sur les horaires de bureau.
Début août nous avons mis en place une nouvelle version d’Onlyoffice (l’outil que nous utilisons pour l’édition collaborative). Nous avons tardé à mettre cette nouvelle version en place car n’inclue pas l’édition collaborative via mobile (limitation liée à la licence gratuite que nous utilisons).
Malheureusement, et nous ne savons toujours pas pourquoi, cela à entraîné la perte de service sur notre Onlyoffice existant, que nous n’avons pas réussi à remettre sur pied rapidement. Nous avons donc décidé de basculer tous les Nextcloud sur ce nouvel Onlyoffice. Nous avons mis plusieurs jours à nous rendre compte de la panne (grâce à vos retours) mais tout est finalement rentré dans l’ordre. Nous sommes désolés de la gêne que cela a pu créer.
Nextcloud / mutu3
Début août (le 8), suite à une insomnie et des moustiques, nous avions une plage horaire calme pour faire des maintenances sur nos serveurs. La cible fut le serveur nommé mutu3, qui héberge plusieurs Nextclouds, notre Onlyoffice et un Mattermost. Mutu3 n’avais pas été redémarré depuis 33 semaines (ce qui est une mauvaise pratique) et son Swap était utilisé à 100%. Nous l’avons donc redémarré, et profiter de l’occasion pour tenter de chiffrer sa partition principale (root). La manipulation a malheureusement été un échec (et nous n’avons pas d’accès IPMI sur ce serveur, donc pas de visibilié au démarrage), et nous avons dû redémarrer sur l’ancien système de fichier (non chiffré). Cette opération a pris plusieurs heures.
Résultat : mutu3 (et les services associés) était HS le 08/08 de 6h25 à 9h07 du matin.
N’hésitez pas à passer une tête notre espace de discussion Mattermost si vous souhaitez plus de détails 👍
Comme d’habitude, vous avez été très patient.e.s et tolérant.e.s et nous vous en remercions.