Ayant simultanément ressenti un trouble dans la force, vos administrateurs des serveurs LinuxFr.org ont noté un souci sur le site hier matin. Et d'autres personnes de l'équipe ont aussi signalé le problème (supervision efficace et réactive par le lectorat).
Le serveur hébergeant les conteneurs de production et de développement a redémarré (hors de toute opération planifiée) à 06h15 Paris le 26 juin 2025, et contrairement aux redémarrages habituels pour les mises à jour, cela a entraîné un changement des adresses IP internes des conteneurs de production et de développement, après redémarrage (06h18). Tous les services avaient bien redémarré, mais les accès aux sites web n'étaient plus possibles : le serveur web frontal ne pouvait plus joindre les adresses prévues, aboutissant à des réponses techniques 502 Bad Gateway.
La correction sur les adresses IP a été faite à 08h08 pour la production et 08h16 pour le développement.
Les deux autres serveurs hébergés au même endroit n'ont pas été affectés.
Changement d'adresses IP
Les conteneurs de production et de développement sont configurés en DHCP et gardent normalement les mêmes adresses sur les redémarrages.
Exemple de redémarrage propre pour des mises à jours de sécurité :
mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPREQUEST(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPACK(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa prod
mai 24 10:06:22 oups dnsmasq-dhcp[1256]: DHCPRELEASE(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
---redémarrage---
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPDISCOVER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPOFFER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPREQUEST(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPACK(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb prod
(les IP, MAC et interfaces ont été changées)
On a demande et attribution de l'IP pour une adresse MAC donnée, puis elle est relâchée à l'arrêt de la machine, puis réattribuée au démarrage.
Incident :
juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPREQUEST(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc
juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPACK(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc prod
---redémarrage---
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPNAK(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd address in use
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPDISCOVER(lxc0) dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPOFFER(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPACK(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd prod
On a demande et attribution de l'IP pour une adresse MAC donnée. Elle n'est pas relâchée à l'arrêt de la machine, n'est pas disponible au redémarrage, et une autre est alors attribuée.
Nature du redémarrage
Le redémarrage a été brutal, sans arrêt propre des services. Il ne s'agit donc pas d'un arrêt logiciel propre depuis le serveur.
La cause possible peut donc être un souci d'instabilité électrique, l'arrêt/extinction physique sur le serveur, un bug ou une faille logicielle, ou encore le redémarrage électrique via la carte d'administration. Cette cause n'est actuellement pas connue.
Mesures préventives et correctives
Il pourrait être utile de figer les IP internes et/ou d'assurer la synchronisation/reconfiguration du frontal web.
Il n'est pas prévu d'avoir de la redondance sur la production à court/moyen terme, donc un souci sur le conteneur de production continuera à avoir un effet visible.
La supervision peut certainement être améliorée (et l'état des services rendu visible depuis un simple navigateur web).
# C'est sans doute lié à l'orage
Posté par Stéphane Ascoët (site web personnel) . Évalué à 5 (+4/-0).
Je ne l'ai pas entendu sur les médias, mais il y a bien une coupure électrique sur une partie sud de Paris depuis la nuit du 25 au 26. J'en sais quelque chose… notre salle serveur n'étant pas redondée faute de budget (mais ça n’empêche pas le dictateur d'appeler les chercheurs états-uniens réprimés à venir chez nous, de prétendre qu'on va devenir des meneurs dans l'IA, etc.), c'est le branle-bas de combat depuis cette fameuse nuit pour transférer des VMs à la main vers les machines d'un autre site. Bon là le courant vient d'être rétabli et les grosses têtes commencent à se détendre… mais il reste à échelonner le démarrage des équipements et machines bien sûr, il y en a encore pour deux/trois heures. J'ai demandé un archivage de la page contenant de vagues informations
[^] # Re: C'est sans doute lié à l'orage
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 27 juin 2025 à 12:56.
Je dois dire que ceci laisse rêveuse :
Les gens ne peuvent même plus aller bosser parce qu'ils ne peuvent plus entrer dans leur bureau. Cela dit, si leur boulot se fait essentiellement avec un ordinateur, de toute façon, iels ne peuvent pas travailler.
Une direction intelligente leur filerait une journée de relâche payée hors congés et récupération, naturellement.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: C'est sans doute lié à l'orage
Posté par Voltairine . Évalué à 3 (+2/-1).
Et inventerait ainsi le chômage technique. Brillant.
[^] # Pas sûr… Re: C'est sans doute lié à l'orage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 27 juin 2025 à 15:14.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.