Pershendetje te gjitheve! Emri im është Dmitry Samsonov, unë punoj si administrator kryesor i sistemit në Odnoklassniki. Ne kemi më shumë se 7 mijë serverë fizikë, 11 mijë kontejnerë në cloud dhe 200 aplikacione, të cilat në konfigurime të ndryshme formojnë 700 grupe të ndryshme. Shumica dërrmuese e serverëve ekzekutojnë CentOS 7.
Më 14 gusht 2018, u publikua informacioni në lidhje me cenueshmërinë FragmentSmack
() dhe SegmentSmack (). Këto janë dobësi me një vektor sulmi në rrjet dhe një rezultat mjaft të lartë (7.5), i cili kërcënon mohimin e shërbimit (DoS) për shkak të shterimin e burimeve (CPU). Një rregullim i kernelit për FragmentSmack nuk u propozua në atë kohë; për më tepër, ai doli shumë më vonë se publikimi i informacionit në lidhje me cenueshmërinë. Për të eliminuar SegmentSmack, u sugjerua përditësimi i kernelit. Vetë paketa e përditësimit u lëshua në të njëjtën ditë, gjithçka që mbeti ishte instalimi i tij.
Jo, nuk jemi aspak kundër përditësimit të kernelit! Megjithatë, ka nuanca...
Si e përditësojmë kernelin në prodhim
Në përgjithësi, asgjë e komplikuar:
- Shkarko paketat;
- Instaloni ato në një numër serverësh (përfshirë serverët që presin renë tonë);
- Sigurohuni që asgjë të mos prishet;
- Sigurohuni që të gjitha cilësimet standarde të kernelit të aplikohen pa gabime;
- Prisni disa ditë;
- Kontrolloni performancën e serverit;
- Kaloni vendosjen e serverëve të rinj në kernelin e ri;
- Përditësoni të gjithë serverët sipas qendrës së të dhënave (një qendër të dhënash në të njëjtën kohë për të minimizuar efektin tek përdoruesit në rast të problemeve);
- Rinisni të gjithë serverët.
Përsëriteni për të gjitha degët e bërthamave që kemi. Për momentin është:
- Stock CentOS 7 3.10 - për shumicën e serverëve të rregullt;
- Vanilje 4.19 - për tonën , sepse na duhen BFQ, BBR, etj.;
- Elrepo kernel-ml 5.2 - për , sepse 4.19 dikur sillej i paqëndrueshëm, por nevojiten të njëjtat veçori.
Siç mund ta keni marrë me mend, rinisja e mijëra serverëve kërkon kohën më të gjatë. Meqenëse jo të gjitha dobësitë janë kritike për të gjithë serverët, ne rinisim vetëm ata që janë të aksesueshëm drejtpërdrejt nga Interneti. Në cloud, për të mos kufizuar fleksibilitetin, ne nuk lidhim kontejnerë të aksesueshëm nga jashtë me serverë individualë me një kernel të ri, por rinisim të gjithë hostet pa përjashtim. Për fat të mirë, procedura atje është më e thjeshtë sesa me serverët e rregullt. Për shembull, kontejnerët pa shtetësi thjesht mund të zhvendosen në një server tjetër gjatë një rindezjeje.
Megjithatë, ka ende shumë punë dhe mund të duhen disa javë, dhe nëse ka ndonjë problem me versionin e ri, deri në disa muaj. Sulmuesit e kuptojnë shumë mirë këtë, kështu që ata kanë nevojë për një plan B.
FragmentSmack/SegmentSmack. Zgjidhje
Për fat të mirë, për disa dobësi ekziston një plan i tillë B, dhe quhet Workaround. Më shpesh, ky është një ndryshim në cilësimet e kernelit/aplikacionit që mund të minimizojë efektin e mundshëm ose të eliminojë plotësisht shfrytëzimin e dobësive.
Në rastin e FragmentSmack/SegmentSmack Zgjidhje si kjo:
«Ju mund t'i ndryshoni vlerat e paracaktuara prej 4 MB dhe 3 MB në net.ipv4.ipfrag_high_thresh dhe net.ipv4.ipfrag_low_thresh (dhe homologët e tyre për ipv6 net.ipv6.ipfrag_high_thresh dhe net.ipv6.ipfrag_low_thresh) në përkatësisht 256 k192 ose B262144 më të ulëta. Testet tregojnë rënie të vogla deri të konsiderueshme në përdorimin e CPU-së gjatë një sulmi në varësi të harduerit, cilësimeve dhe kushteve. Megjithatë, mund të ketë njëfarë ndikimi në performancë për shkak të ipfrag_high_thresh=64 bajt, pasi vetëm dy fragmente XNUMXK mund të futen në radhën e rimontimit në të njëjtën kohë. Për shembull, ekziston rreziku që aplikacionet që punojnë me pako të mëdha UDP të prishen'.
Vetë parametrat përshkruar si më poshtë:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Ne nuk kemi UDP të mëdha për shërbimet e prodhimit. Nuk ka trafik të fragmentuar në LAN; ka trafik të fragmentuar në WAN, por jo domethënës. Nuk ka shenja - ju mund të hapni Zgjidhjen!
FragmentSmack/SegmentSmack. Gjaku i parë
Problemi i parë që hasëm ishte se kontejnerët e cloud ndonjëherë aplikonin cilësimet e reja vetëm pjesërisht (vetëm ipfrag_low_thresh), dhe ndonjëherë nuk i zbatonin fare - ato thjesht rrëzoheshin në fillim. Nuk ishte e mundur të riprodhohej problemi në mënyrë të qëndrueshme (të gjitha cilësimet u aplikuan manualisht pa ndonjë vështirësi). Të kuptuarit pse kontejneri rrëzohet në fillim nuk është gjithashtu aq i lehtë: nuk u gjetën gabime. Një gjë ishte e sigurt: rikthimi i cilësimeve zgjidh problemin me përplasjet e kontejnerëve.
Pse nuk mjafton të aplikoni Sysctl në host? Kontejneri jeton në hapësirën e emrave të rrjetit të vet të dedikuar, kështu të paktën në enë mund të ndryshojnë nga pritësi.
Si aplikohen saktësisht cilësimet e Sysctl në kontejner? Meqenëse kontejnerët tanë janë të paprivilegjuar, ju nuk do të mund të ndryshoni asnjë cilësim Sysctl duke hyrë në vetë kontejnerin - thjesht nuk keni të drejta të mjaftueshme. Për të drejtuar kontejnerët, reja jonë në atë kohë përdorte Docker (tani ). Parametrat e kontejnerit të ri iu kaluan Docker përmes API-së, duke përfshirë cilësimet e nevojshme të Sysctl.
Gjatë kërkimit nëpër versione, rezultoi se Docker API nuk i ktheu të gjitha gabimet (të paktën në versionin 1.10). Kur u përpoqëm të nisnim kontejnerin përmes "docker run", më në fund pamë të paktën diçka:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
Vlera e parametrit nuk është e vlefshme. Por pse? Dhe pse nuk vlen vetëm ndonjëherë? Doli që Docker nuk garanton rendin në të cilin janë aplikuar parametrat Sysctl (versioni i fundit i testuar është 1.13.1), kështu që ndonjëherë ipfrag_high_thresh u përpoq të vendosej në 256K kur ipfrag_low_thresh ishte ende 3M, domethënë kufiri i sipërm ishte më i ulët se kufiri i poshtëm, i cili çoi në gabim.
Në atë kohë, ne kemi përdorur tashmë mekanizmin tonë për rikonfigurimin e kontejnerit pas fillimit (ngrirja e kontejnerit pas dhe ekzekutimi i komandave në hapësirën e emrave të kontejnerit nëpërmjet ), dhe ne gjithashtu shtuam parametrat e shkrimit Sysctl në këtë pjesë. Problemi u zgjidh.
FragmentSmack/SegmentSmack. Gjaku i Parë 2
Përpara se të kishim kohë për të kuptuar përdorimin e Workaround në re, filluan të vinin ankesat e para të rralla nga përdoruesit. Në atë kohë, kishin kaluar disa javë nga fillimi i përdorimit të Workaround në serverët e parë. Nga hetimet fillestare ka rezultuar se ankesa janë pranuar ndaj shërbimeve individuale dhe jo të gjithë serverëve të këtyre shërbimeve. Problemi është bërë përsëri jashtëzakonisht i pasigurt.
Para së gjithash, natyrisht, ne u përpoqëm të rikthejmë cilësimet e Sysctl, por kjo nuk pati asnjë efekt. Nuk ndihmuan as manipulime të ndryshme me cilësimet e serverit dhe aplikacionit. Rindezja ndihmoi. Rindezja e Linux-it është po aq e panatyrshme sa ishte normale për Windows në kohët e vjetra. Megjithatë, ajo ndihmoi dhe ne e shquanim atë me një "gabim të kernelit" kur aplikonim cilësimet e reja në Sysctl. Sa e pavlerë ishte ...
Tre javë më vonë problemi u përsërit. Konfigurimi i këtyre serverëve ishte mjaft i thjeshtë: Nginx në modalitetin proxy/balancer. Jo shumë trafik. Shënim i ri hyrës: numri i 504 gabimeve tek klientët po rritet çdo ditë (). Grafiku tregon numrin e 504 gabimeve në ditë për këtë shërbim:
Të gjitha gabimet kanë të bëjnë me të njëjtin fund - në lidhje me atë që është në re. Grafiku i konsumit të kujtesës për fragmentet e paketave në këtë sfond dukej kështu:
Ky është një nga manifestimet më të dukshme të problemit në grafikët e sistemit operativ. Në renë kompjuterike, pikërisht në të njëjtën kohë, u rregullua një problem tjetër i rrjetit me cilësimet QoS (Traffic Control). Në grafikun e konsumit të kujtesës për fragmentet e paketave, dukej saktësisht e njëjtë:
Supozimi ishte i thjeshtë: nëse duken njësoj në grafikë, atëherë ata kanë të njëjtën arsye. Për më tepër, çdo problem me këtë lloj memorie është jashtëzakonisht i rrallë.
Thelbi i problemit fiks ishte se ne përdorëm programuesin e paketave fq me cilësimet e paracaktuara në QoS. Si parazgjedhje, për një lidhje, ju lejon të shtoni 100 pako në radhë dhe disa lidhje, në situata të mungesës së kanalit, filluan të bllokojnë radhën në kapacitet. Në këtë rast, paketat hidhen. Në statistikat tc (tc -s qdisc) mund të shihet si kjo:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
"464545 flows_plimit" është paketat e hequra për shkak të tejkalimit të kufirit të radhës së një lidhjeje, dhe "dropped 464545" është shuma e të gjitha paketave të hequra të këtij planifikuesi. Pas rritjes së gjatësisë së radhës në 1 mijë dhe rinisjes së kontejnerëve, problemi pushoi së shfaquri. Mund të uleni dhe të pini një smoothie.
FragmentSmack/SegmentSmack. Gjaku i fundit
Së pari, disa muaj pas shpalljes së dobësive në kernel, më në fund u shfaq një rregullim për FragmentSmack (më lejoni t'ju kujtoj se së bashku me njoftimin në gusht, u lëshua një rregullim vetëm për SegmentSmack), i cili na dha një shans për të braktisur Workaround, që na shkaktoi mjaft telashe. Gjatë kësaj kohe, ne kishim arritur tashmë të transferonim disa nga serverët në kernelin e ri, dhe tani duhej të fillonim nga e para. Pse e përditësuam kernelin pa pritur rregullimin e FragmentSmack? Fakti është se procesi i mbrojtjes kundër këtyre dobësive përkoi (dhe u bashkua) me procesin e përditësimit të vetë CentOS (që kërkon edhe më shumë kohë sesa përditësimi vetëm i kernelit). Për më tepër, SegmentSmack është një cenueshmëri më e rrezikshme dhe një rregullim për të u shfaq menjëherë, kështu që gjithsesi kishte kuptim. Megjithatë, ne nuk mundëm thjesht të përditësojmë kernelin në CentOS sepse dobësia FragmentSmack, e cila u shfaq gjatë CentOS 7.5, u rregullua vetëm në versionin 7.6, kështu që na u desh të ndalonim përditësimin në 7.5 dhe të fillonim përsëri me përditësimin në 7.6. Dhe kjo ndodh gjithashtu.
Së dyti, ankesat e rralla të përdoruesve për probleme janë kthyer tek ne. Tani e dimë me siguri se të gjitha ato lidhen me ngarkimin e skedarëve nga klientët në disa nga serverët tanë. Për më tepër, një numër shumë i vogël ngarkimesh nga masa totale kaluan nëpër këta serverë.
Siç e kujtojmë nga historia e mësipërme, kthimi prapa Sysctl nuk ndihmoi. Rindezja ndihmoi, por përkohësisht.
Dyshimet në lidhje me Sysctl nuk u hoqën, por këtë herë ishte e nevojshme të mblidheshin sa më shumë informacion. Kishte gjithashtu një mungesë të madhe të aftësisë për të riprodhuar problemin e ngarkimit tek klienti në mënyrë që të studiohej më saktë se çfarë po ndodhte.
Analiza e të gjitha statistikave dhe regjistrave të disponueshëm nuk na afroi të kuptojmë se çfarë po ndodhte. Kishte një mungesë akute të aftësisë për të riprodhuar problemin në mënyrë që të "ndihej" një lidhje specifike. Më në fund, zhvilluesit, duke përdorur një version të veçantë të aplikacionit, arritën të arrijnë një riprodhim të qëndrueshëm të problemeve në një pajisje testuese kur lidhen me Wi-Fi. Ky ishte një përparim në hetim. Klienti u lidh me Nginx, i cili u proksua në backend, i cili ishte aplikacioni ynë Java.
Dialogu për problemet ishte si ky (i fiksuar në anën e përfaqësuesit Nginx):
- Klienti: kërkoni të merrni informacione për shkarkimin e një skedari.
- Serveri Java: përgjigje.
- Klienti: POST me skedar.
- Serveri Java: gabim.
Në të njëjtën kohë, serveri Java shkruan në regjistrin se 0 bajt të dhëna janë marrë nga klienti, dhe përfaqësuesi Nginx shkruan se kërkesa mori më shumë se 30 sekonda (30 sekonda është koha e skadimit të aplikacionit të klientit). Pse skadimi dhe pse 0 bajt? Nga perspektiva HTTP, gjithçka funksionon siç duhet, por POST me skedarin duket se zhduket nga rrjeti. Për më tepër, ajo zhduket midis klientit dhe Nginx. Është koha për të armatosur veten me Tcpdump! Por së pari ju duhet të kuptoni konfigurimin e rrjetit. Proxy Nginx është prapa balancuesit L3 . Tuneli përdoret për të shpërndarë paketat nga balancuesi L3 në server, i cili shton kokat e tij në paketa:
Në këtë rast, rrjeti vjen në këtë server në formën e trafikut të etiketuar Vlan, i cili gjithashtu shton fushat e veta në paketat:
Dhe ky trafik mund të jetë gjithashtu i fragmentuar (e njëjta përqindje e vogël e trafikut të fragmentuar hyrës për të cilin folëm kur vlerësuam rreziqet nga Workaround), i cili gjithashtu ndryshon përmbajtjen e titujve:
Edhe një herë: paketat janë të kapsuluara me një etiketë Vlan, të kapsuluara me një tunel, të fragmentuara. Për të kuptuar më mirë se si ndodh kjo, le të gjurmojmë rrugën e paketës nga klienti në përfaqësuesin Nginx.
- Paketa arrin balancuesin L3. Për rrugëtim të saktë brenda qendrës së të dhënave, paketa mbyllet në një tunel dhe dërgohet në kartën e rrjetit.
- Meqenëse kokat e paketës + tunelit nuk përshtaten në MTU, paketa pritet në fragmente dhe dërgohet në rrjet.
- Ndërprerësi pas balancuesit L3, kur merr një paketë, i shton një etiketë Vlan dhe e dërgon atë.
- Ndërprerësi përpara përfaqësuesit Nginx sheh (bazuar në cilësimet e portit) që serveri pret një paketë të kapsuluar në Vlan, kështu që e dërgon atë siç është, pa hequr etiketën Vlan.
- Linux merr fragmente të paketave individuale dhe i bashkon ato në një paketë të madhe.
- Më pas, paketa arrin në ndërfaqen Vlan, ku shtresa e parë hiqet prej saj - kapsulimi Vlan.
- Linux pastaj e dërgon atë në ndërfaqen e Tunelit, ku një shtresë tjetër hiqet prej saj - kapsulimi i tunelit.
Vështirësia është t'i kalosh të gjitha këto si parametra te tcpdump.
Le të fillojmë nga fundi: a ka pako IP të pastra (pa tituj të panevojshëm) nga klientët, me kapsulim vlan dhe tunel të hequr?
tcpdump host <ip клиента>
Jo, nuk kishte paketa të tilla në server. Pra, problemi duhet të jetë atje më herët. A ka ndonjë pako me vetëm kapsulimin Vlan të hequr?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx është adresa IP e klientit në format hex.
32:4 — adresa dhe gjatësia e fushës në të cilën IP SCR është shkruar në paketën Tunel.
Adresa e fushës duhej të zgjidhej me forcë brutale, pasi në internet ata shkruajnë rreth 40, 44, 50, 54, por nuk kishte asnjë adresë IP atje. Ju gjithashtu mund të shikoni një nga paketat në hex (parametri -xx ose -XX në tcpdump) dhe të llogarisni adresën IP që dini.
A ka fragmente të paketave pa kapsulimin e Vlan dhe Tunelit?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Kjo magji do të na tregojë të gjitha fragmentet, duke përfshirë edhe atë të fundit. Ndoshta, e njëjta gjë mund të filtrohet nga IP, por nuk u përpoqa, sepse nuk ka shumë paketa të tilla, dhe ato që më duheshin u gjetën lehtësisht në rrjedhën e përgjithshme. Këtu ata janë:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Këto janë dy fragmente të një pakete (e njëjta ID 53652) me një fotografi (fjala Exif është e dukshme në paketën e parë). Për faktin se ka paketa në këtë nivel, por jo në formën e bashkuar në deponitë, problemi është qartësisht tek montimi. Më në fund ka prova dokumentare për këtë!
Dekoderi i paketave nuk zbuloi ndonjë problem që do të parandalonte ndërtimin. E provova këtu: . Në fillim, kur përpiqeni të mbushni diçka atje, dekoderit nuk i pëlqen formati i paketës. Doli se kishte disa oktete shtesë midis Srcmac dhe Ethertype (jo të lidhura me informacionin e fragmentit). Pas heqjes së tyre, dekoderi filloi të punojë. Megjithatë, nuk shfaqi probleme.
Çfarëdo që mund të thuhet, asgjë tjetër nuk u gjet përveç atyre Sysctl. E tëra që mbetej ishte gjetja e një mënyre për të identifikuar serverët me probleme në mënyrë që të kuptonte shkallën dhe të vendoste për veprime të mëtejshme. Numri i kërkuar u gjet mjaft shpejt:
netstat -s | grep "packet reassembles failed”
Është gjithashtu në snmpd nën OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"Numri i dështimeve të zbuluara nga algoritmi i ri-montimit të IP-së (për çfarëdo arsye: skadimi i kohës, gabime, etj.)"
Në grupin e serverëve në të cilët u studiua problemi, në dy ky numërues u rrit më shpejt, në dy më ngadalë dhe në dy të tjerë nuk u rrit fare. Krahasimi i dinamikës së këtij numëruesi me dinamikën e gabimeve HTTP në serverin Java zbuloi një korrelacion. Kjo do të thotë, njehsori mund të monitorohet.
Të kesh një tregues të besueshëm të problemeve është shumë i rëndësishëm në mënyrë që të mund të përcaktosh me saktësi nëse kthimi prapa Sysctl ndihmon, pasi nga historia e mëparshme e dimë se kjo nuk mund të kuptohet menjëherë nga aplikacioni. Ky tregues do të na lejojë të identifikojmë të gjitha fushat problematike në prodhim përpara se përdoruesit ta zbulojnë atë.
Pas kthimit të Sysctl, gabimet e monitorimit u ndalën, kështu që u vërtetua shkaku i problemeve, si dhe fakti që rikthimi ndihmon.
Kemi rikthyer cilësimet e fragmentimit në serverë të tjerë, ku hyri në lojë monitorimi i ri dhe diku ndamë edhe më shumë memorie për fragmente sesa ishte parazgjedhja më parë (kjo ishte statistika UDP, humbja e pjesshme e të cilave nuk ishte e dukshme në sfondin e përgjithshëm) .
Pyetjet më të rëndësishme
Pse janë të fragmentuara paketat në balancuesin tonë L3? Shumica e paketave që vijnë nga përdoruesit te balancuesit janë SYN dhe ACK. Madhësitë e këtyre pakove janë të vogla. Por meqenëse pjesa e paketave të tilla është shumë e madhe, në sfondin e tyre nuk vumë re praninë e paketave të mëdha që filluan të fragmentohen.
Arsyeja ishte një skenar i prishur i konfigurimit në serverë me ndërfaqe Vlan (në atë kohë kishte shumë pak serverë me trafik të etiketuar në prodhim). Advmss na lejon t'i përcjellim klientit informacionin se paketat në drejtimin tonë duhet të jenë më të vogla në përmasa në mënyrë që pasi t'i bashkojmë kokat e tunelit në to, ato të mos jenë të fragmentuara.
Pse nuk ndihmoi rikthimi i Sysctl, por rindizja? Rikthimi i Sysctl ndryshoi sasinë e memories së disponueshme për bashkimin e paketave. Në të njëjtën kohë, me sa duket vetë fakti i tejmbushjes së kujtesës për fragmente çoi në ngadalësimin e lidhjeve, gjë që çoi në vonimin e fragmenteve për një kohë të gjatë në radhë. Kjo do të thotë, procesi shkoi në cikle.
Rindezja pastroi kujtesën dhe gjithçka u kthye në rregull.
A ishte e mundur të bëhej pa zgjidhje? Po, por ekziston një rrezik i lartë për t'i lënë përdoruesit pa shërbim në rast sulmi. Sigurisht, përdorimi i Workaround rezultoi në probleme të ndryshme, duke përfshirë ngadalësimin e një prej shërbimeve për përdoruesit, por megjithatë ne besojmë se veprimet ishin të justifikuara.
Shumë faleminderit për Andrey Timofeev () për ndihmë në kryerjen e hetimit, si dhe Alexey Krenev () - për punën titanike të përditësimit të Centos dhe bërthamave në serverë. Një proces që në këtë rast u desh disa herë të nisej nga fillimi, ndaj dhe u zvarrit për shumë muaj.
Burimi: www.habr.com