#lurkerchangelog / ależ fakap!! od soboty(!) były problemy z działaniem apki. od teraz wszystko powinno być OK. jesli jeszcze raz komuś będzie pulsować logo w nieskończoność, bardzo proszę o pilny kontakt (oczywiście jeśli F5 nie rozwiąże sprawy )

ja pitole!!! …pod spodem opis ciekawego kejsu, jak to próbowałem narzędziami sieciowymi monitorować, w którym miejscu firewall wycina ludzi (jedne IP mogły wchodzić na stronę, inne w ogóle), a okazało się cos zupełnie innego

1) w sobotę u siebie na Debianie zrobiłem upgrade systemu (robię raz na miesiąc średnio);
2) zaktualizował się także node.js, z wersji v14.12 na v14.13;
3) robiłem w międzyczasie dużo buildów i deployów na serwer (update funkcji, bo codziennie coś tam kodzę);
4) wszystkie paczki (moduły npm) instalują się po stronie serwera (npm install);
5) ale… jeden z nich się mocno wyróżnia. nazywa się bcrypt. to jest plugin, ktory wymaga skompilowania i przy zmianie wersji node-a, trzeba ją zrobić ponownie;
6) na serwerze (do teraz) miałem wersję node v14.12 (a u siebie, od soboty, v14.13), bcrypt nie działała jak trzeba;
7) ten moduł (bcrypt) na lurku służy m.in do resetowania hasła (hashuje nowe hasło usera). za każdym razem, jak ktoś resetował hasło, ubijał workera;
8) na serwerze jest 6 workerów - są one przypisane do klientów przez adres IP (tzw. ip-hash, zamiast klasycznego round-robin), 1 user = 1 przypisanie workera na stałe (bo korzystamy z socketów i to nie może byc zmieniane w locie);
9) jak worker padł, ludzie nadal byli do niego przypisani (to nie było klasyczne padnięcie, że pm2 może zrobić reset workera, a proxy-server przekierować ruch na nowy worker), ale ciche padnięcie, które nie zwracało żadnych błedów, a po prostu zwieszało worker na amen (robił się wieczny pending i timeout ubijał połaczenie, zero info w logach, gdziekolwiek);

tak wiec nie było problemu z firewallem… niemniej tak: z jednych adresów (przypisanych do "martwych" workerów) nie dało się wchodzić, podczas gdy inne adresy IP działały bez zarzutu. (a więc po długiej batalii, gdzie najpierw sprawdzałem czemu PWA na telefonie nie śmiga, a potem proxy z Bułgarii, a potem jeszcze inne rzeczy), eh.. cieezki temat

to tak w skrócie jesli ktoś jeszcze doświadczy pulsującego loga, proszę o info, bo to wówczas bedzie znaczyło, ze to nie było to (ale to było to ). daję sobie 48h na testy, jak sie w tym czasie ani razu nie wysypie, bedzie ok. nie bede resetować workerów, czyli finalnie wszystkie padną i apka (dla każdego) przestanie działac, co bedzie potwierdzeniem, że jest nadal lipa (ale nie powinna być).

POZDRO!

21

@Thanos, znowu to samo - pulsujące logo.
Odpaliłem VPN-a i wszedłem bez problemu.
@Ostry_Burrito, analiza trwa. cos jest na rzeczy
@Thanos, Cholera, a ja myślałem, że pomogła reinstalacja systemu na moim lapku.
@wiktor, uuu… bardzo mi przykro, ale to nie to

(btw. bład nadal wystepuje, ale jestem juz bliski jego namierzenia )
@Thanos, Thanos na prezydenta!
@Thanos, dzisiaj przed 15 minutami tak mialem i jeszcze wczesniej rano. wczoraj chyba raz. ale w miedzyczasie udawalo sie wejsc.
@Thanos, ja bym sobie zrobił jakiś skrypcik z crona monitorujący workery i restartujący (+mail że fuckup nastąpił). Po prostu zautomatyzuje fuckupy.
Czy to monitor na procesy, czy na logi (np. brak nowych logów ;p)
@bmpte, mam takie narzędzia (wszystko jest monitorowane + restartowane, workery przełączane etc.).

tylko że te workery nie były do końca martwe. status był ok. to były workery zombie

po prostu przyjmowały request i …nic dalej się nie działo. nie mogłem tego wyłapać na żadnym etapie (ale niby działały )
@Thanos, a w ps miały status Z (zombie)?
@bmpte, to było coś w samej apce (wyglądała na zdrową). load-balancer ma wbudowany tego typu monitoring. dostawał widocznie dobrą odpowiedź, skoro nadal tam kierowal.
@Thanos, Uhm, ale można zrobić monitor łączący się do konkretnego workera (z pominięciem loadbalancera) tzn. wrk'iem który prosi o stronę i w przypadku odpowiedzi zerowej (lub wykminionej jako awaria) restartujący. niby proteza - ale dzisiaj siadło z powodu bcrypta, jutro może pieprznąć z powodu czegokolwiek innego…
@bmpte, ok, śledztwo idzie dalej. cos jest na rzeczy.

sam worker dziala dobrze (przetesetowalem go, kazdy z osobna, bo znowu wywaliło ), ale jak puszczam przez load-balancer (nginx), to jest lipa calkowita…

no nie wiem do konca. mega zagadka. musze to dzisiaj naprawić
@Thanos, hm… limity?
moze open sockets, może coś na conntracku, może nginx ma defaultowe niskie jakieś a nie ustawiłeś większych …
no, szukaj