Open cquest opened 3 years ago
Bonjour,
j'ai toujours le 502 bad gateway, sur http://umap.openstreetmap.fr/.
Un dig sur les serveurs DNS Free et Google donne : umap.openstreetmap.fr. 9463 IN CNAME osm27.openstreetmap.fr.
.
Est-ce normal ?
Bon courage. Cordialement.
Le CNAME est correct, les CT d'osm26 et osm27 étaient eux aussi tombés, tout est à nouveau UP pour eux, dont umap. Pour osm28, une partie seulement des CT UP (osmose, forum et educosm down), toujours pas de quorum, pas de vrack, pas de news d'OVH...
J'ai pu remettre osm28 dans le vRack, car hier soir en voulant le retirer et le remettre via le manager web d'OVH, une fois retiré, il n'était plus sélectionnable. Donc là, en principe il devrait y être... sauf que ça ne fonctionne pas.
Il va falloir en appeler au vaudou.
j'ai toujours le 502 bad gateway, sur http://umap.openstreetmap.fr/.
Ça marche pour moi désormais. Merci.
Merci pour les investigation, @cquest !
utiliser rsync pour recopier régulièrement les config nginx au lieu d'un accès NFS
J'avais mis un NFS surtout pour que les fichiers mis par acme dans .well-known/acme-challenge/
soient accessibles de tous les proxy lors du test fait par Letsencrypt.
Par contre, c'est vrai que le certif généré pourrait être copié en local après génération. Je regarderais pour modifier le script.
Bon... peu de progrès, mais une confirmation, c'est bien osm28 qui est hors vrack, je viens de vérifier et osm25 ping bien osm26 et osm27.
Support OVH en DM sur twitter... mais toujours pas de réponse à mon ticket d'hier soir.
J'ai pu refaire fonctionner le cluster, en créant un ring redondant (c'est à dire une seconde adresse IP pour chaque noeud). Du coup quorum revenu à la normale et osm28 accepte de démarrer les CT donc sont UP à nouveau: forum, mastodon, peertube, educosm
Ce qui ne fonctionne toujours pas c'est la réplication qui passe par le vRack, ainsi que le trafic de proxy.
Toujours pas de news d'OVH... relancé par DM twitter...
osmose UP... après avoir compris qu'osm153 n'était plus le CT du frontend osmose. Pourquoi tourne-t-il encore ?
overpass UP: il n'avait pas aimé le reboot de son host.
osmose UP... après avoir compris qu'osm153 n'était plus le CT du frontend osmose. Pourquoi tourne-t-il encore ?
overpass UP: il n'avait pas aimé le reboot de son host.
- un fichier résiduel empêchait le dispatcher de démarrer
tu as un extrait du log/journal à ce sujet ?
car le journal dit qu'il était bloqué par
dispatcher[2554]: File_Error No such file or directory 2 /osm3s_v0.7.54_osm_base Dispatcher_Client::1
le fichier socket que l'upstream conseillait (à tord à mon avis) de ne pas effacer automatiquement, ce qui bloque au reboot "qui n'arrive jamais"
Le log dit aussi (ligne juste avant):
juin 14 15:04:18 osm147 dispatcher[3072]: File_Error Address already in use 98 /data/project/overpass/database//osm3s_v0.7.54_osm_base Unix_Socket::4
En le supprimant, plus de "in use" et donc plus d'erreur et le service démarre. Le plus simple serait qu'il soit en /tmp ou /dev/shm donc supprimé au reboot, ou alors ajouter l'effacement dans un "pre" de systemd pour ce service.
Sinon, le vRack est de retour, la panne provenait d'un switch pour toute la baie: http://travaux.ovh.com/?do=details&id=51273& J'ai reçu un mail à 22h38 indiquant la cause. Comme un idiot j'étais tombé sur status.ovh.com (visiblement oublié)... et pas travaux.ovh.com
Le bon côté des choses... les 3 serveurs du cluster ont été mis à jour en proxmox 6.4 :)
J'ai complété l'issue de départ avec 3 points à améliorer.
Le log dit aussi (ligne juste avant):
juin 14 15:04:18 osm147 dispatcher[3072]: File_Error Address already in use 98 /data/project/overpass/database//osm3s_v0.7.54_osm_base Unix_Socket::4
En le supprimant, plus de "in use" et donc plus d'erreur et le service démarre
oui c'est bien cela le soucis au reboot mais c'est le socket entre le dispatcher et les autres processus, pas le timestamp dont tu parles. J'ai viré le fichier socket du dispatcher area qui était tjs là pour faire redémarer le dispatcher correspondant pour son emplacement, c'est dans son ticket
Le timestamp était une erreur de copier/coller, désolé.
Le problème de certificat https est corrigé par https://github.com/osm-fr/ansible-scripts/commit/8cc0220b902ee3cbf7183d17ffbfa20c0020a927
Hier soir, la connexion entre osm28 et le reste du cluster OVH (osm26/osm27) a été perdue ~pour une raison inconnue~ à la suite d'un panne du switch OVH assurant l'interconnexion des vRack.
Un ticket a été ouvert au support OVH à ce sujet.
Conséquences:
Premières actions (Jocelyn et cquest):
Résultats:
Secondes actions (cquest):
pvecm expected 1
sur osm28 règle le problème de quorum, les CT redémarrent automatiquement mais cela démarre aussi osm144 (umap configuré en haute-dispo) qu'il faut stopper manuellementRésultats:
A améliorer: