Tak ono staci se podivat trocha na coalescing... jak ty zavisle ukoly planovat tak, aby se to nezahltilo.
Problem je velice podobny tomu s cim se musi vyporadat napr cron - pokud ukol trva dele nez hodinu a mate to naplanovano v hourly, tak jaky pristup zvolit? Nasilne dodrzovat plan, ze se to bude poustet co hodinu ale riskujete zahlceni.. anebo se pozadavek vypusti, kdyz dana vec se nestihla dokoncit v ramci sveho periodickeho okna?
To jednak, ale už dinosauři programovali tak, že si to hlídalo samo, zda to neběží dvakrát. Potom se to z cronu dá spouštět každou minutu a poběží to pouze jednou.
doporučuji tohle vyzkoušet, když máš výraznou zátěž (např. násobky počtu jader), pak se ty cron procesy umí přednánět, flock nebo listen socket v tom udělají pěkný čurbes a neplatí, že to běží jen jednou. Naopak u systemd timer se mi tohle nestalo.
Jako dinosauři jsme s tímhle právě problémy měli.
if [ -f lock.file ]
then
touch lock.file
delejNecoUzitecneho.sh
rm lock.file
fi
Lépe (atomicky) to tedy neumím...
No tohle ty neprůstřelné rozhodně není. V těchto scénářích kdy check a vytvoření zámku nejsou atomické se obvykle používá dvojitý check
Není. Vytvoření souboru na FS je atomická operace. Lock soubory se v unixu používají v podstatě od počátku.
Man pro open: O_EXCL - Ensure that this call creates the file: if this flag is specified in conjunction with O_CREAT, and pathname already exists, then open() will fail.
Jé doufám jasný, že tydle “procesy” jsou distribuovaný systémy/služby a ne lokální process co se spouští přes crond?
Reagoval jsem ve vláknu, kde někdo uvedl cron. Pokud distribuovaná služba nepozná, že na stroji běží proces stejné služby spuštěné někým jiným, tak je to špatná služba.
Hlavně to, prosím, neříkejte mému wrapperu na crony, jo? Ještě by se tak po těch letech bezchybného provozu začal chovat.
Zprávička je o tom, že Amazon měl v automatických úlohách spouštěných na pozadí léta chybu race condition, která se projevila teď po letech a v důsledku způsobila chyby mnoha služeb v nejdůležitějším regionu AWS skoro na celý den. Argument „mně to tak léta funguje“ mi pod takovou zprávičkou připadá poněkud bezzubý.
Že je kód, kde by mohlo docházet k race condition, správně, se neověří tak, že ten kód dlouho poběží bezchybně. Ověříte ho jedině tak, že kód projdete, zjistíte, co dělá, jaké jsou předpoklady toho, co dělá, a ověříte, že všechny ty předpoklady jsou splněné.
Je dost možné, že to tak máte, protože zajistit na Linuxu pomocí zamykacího souboru, že proces poběží maximálně jednou, je jednoduché. (Zajistit, že poběží právě jednou, je úplně jiná disciplína.) Ale „běží to dlouho bez chyb“ to nedokazuje.
Ne, zprávička je o race condition na kterou nikdo jaksi nepomyslel. To, na co jsem reagoval, je tvrzení, které jsem si pečlivě ověřoval a nikdy nic takového nenastalo.
Tyhle tasky na velkých infrastrukturach resi typicky globalni nadřazené job plannery. Nikd pricetny tohle nebude řešit přímo na stroji kde task bezi.
28. 10. 2025, 09:53 editováno autorem komentáře
DNS byla jen prvni (kratsi, asi tri hodinova) vlna problemu. Pak nasledovaly dalsi dve, co incident natahly v souctu asi na patnact hodin - a ty byly fatalnejsi. Nejdriv DropletWorkflow Manager starajici se o "pronajmy" pro EC2 umlatil DynamoDB pozadavkama a kdyz se vyhrabali z tohoto, tak si umlatili prozmenu Network Manager starajici se o sitovani EC2 a balancery jako dusledek vyhazovaly instance, ktere kvuli tomu nebyly jeste dostupne. Aneb typicky to cele dopadalo na EC2 s jepicim zivotem.
Realne to ukazalo, ze AWS to nema moc nachystane na nejake disaster-recovery. Automatizace pocitala s beznym cvrkotem, ne s tim ze se to muze vysypat cele.
Azure nebo Google Cloud. Oba proklamují, že jednotlivá lokality řídí samostatně a ani u jednoho se podobný problém nestal, u AWS už ponělikáté jim to spadlo celé kvůli jedné lokalitě.
GCP nemá takový share, zabijí produkty a služby…
Azure má problémy se škálovaním CP pro compute, firewalls na storage, rozbijí vlastní SDK klienty upgradem velikosti certifikátů, nefungující time sync na VMs…
Každý cloud má svoje gotchas, ale AWS je pořád top
GCP zabiji produkty? Ktere? Google ano, ale GCP je v tomto stabilni na urovni AWS, tj. zabiji stare rady compute a verze managed aplikaci, ale jinak pokud vim nic.
Snapshot Debugger (open-source nástroje).gcloud (Google Cloud CLI).Google Cloud je na tom lepe, ale AWS ted nepadlo "cele".
Padl jenom region us-east-1, ktere je default v menu, bezi v nem nektere single-homed interni AWS sluzby a AWS tam deployuje jako prvni. A je tam pulka internetu single-homed, takze manazment a zakaznici lepe chapou, kdyz mate vypadek jako vsichni 18h, nez kdyz mate hodinove spomaleni kvuli vypadku availability zony us-east-2a, o kterem nevi nikdo.
I v Googlu treba multiregion, kdyz chcete 5 devitek.
Azure má každou chvíli nějaký problém. Naposled jeho Front Door nejel pro celou Evropu a blízký východ, snad více než 8 hodin a rozhodně to nebylo letos poprvé. Jejich patchem na AKS nám vyřadili na týden celý cluster a aby se to po týdnu samo opravilo s dalším patchem.
Přesně. Azure sice možná nepadne globálně ale na to, aby mě zcela přešly naivní představy o stabilitě mi stačily dva roky nepříliš intenzivního používání.
Tak Azure se opět vyznamenal jeho Azure Front Door je globálně dole již několik hodin. Takže až tu bude zase nějaký chytrák tvrdit, že Azure je v tomhle lepší, tak ať raději příště pomlčí.
Tak DNS jsou složitá a nespolehlivá služba. Když jsme adminům v minulé práci jako vývojáři reklamovali hlášky typu "Name or service not known" tak nám bylo řečeno že DNS jsou nespolehlivý ;-)
On je v praxi docela problém s negative ttl, tedy že si resolver pamatuje, že nějaký záznam na serveru neexistuje. Problém je, když někdo okopíruje SOA záznam, kde je negative nastaveno třeba na měsíc a klienti se zeptají dřív, než tam ten nový záznam skutečně je. To potom to dns někde funguje a jinde ne podle toho, kdo se kdy zeptal.
Tak ono to pole historicky melo vicero vyznamu (zminuje treba RFC2308)... a lidi jsou radi otroky minulosti, kdy casto SOA proste tupe kopiruji a vlastne nad temi cisly moc nedumaji :-) Takovy zonemaster ma na to i test, ktery hlida rozpeti od 300 do 86400 sekund a cokoliv mimo tento interval failne. Mimo to, resolver se tim ridit ani nemusi - realne to pole rika, jak dlouho muzu tu negativni odpoved drzet, ale je to optional. A treba v Bindu se to ridi pomoci max-ncache-ttl - kdy vychozi hodnota je 3 hodiny a vic nez tyden to ani nezkousne, v Unboundu je to podobne cache-max-negative-ttl, kde default je hodina. Aneb panem sani je ve finale tady spravce resolveru a ne spravce zony... :-)
Akorát, že tady to DNS vlastně vůbec nebylo. Resp. je to stejné jako byste napsal: Vždycky je to IP nebo vždycky je to Ethernet. Protože DNS bylo v tomto případě jenom posel špatných zpráv...
Doporučuju tento kanál na YT: https://www.youtube.com/@kevinfaang
Je to plné podobných příběhů, poslední je o tom, jak zálohovací skript od HP smazal v LUSTRE FS desítky milionů souborů (prostě někdo změnil právě běžící bash skript).
Jo, změnit si pod rukama běžící bash skript, to se mi už taky podařilo. Sice s mnohem menším dopadem, ale i taky si to od té doby hlídám. :D
Já bash moc nepoužívám (pouze onelinery) a tohle mě fakt po těch letech překvapilo. On to bere po řádcích přímo ze souboru.
Takhle fungují snad všechny Unixové shelly (bash, ash, ksh, zsh…). Je to jen o tom, že unixové shelly v době svého vzniku neměly na počítačích k dispozici mnoho RAM (~60. léta, tj. řádově kB). Celý skript do paměti načítají až interpretované jazyky (perl, python, ruby,…) nebo powershell, které parsují celou strukturu souboru (AST), ale to už počítače měly k dispozici řádově MB RAM (~90. léta).
Historickému kontextu rozumím, ale proč je to tak i dnes to netuším. Ten interpretr netřeba měnit, jen stačí načíst ten soubor při otevření celý.
Nebo se někde využívá toho, že skript modifikuje sám sebe při svém běhu?
Ne, ale čas od času může takový 'skript' obsahovat i data. Potom má několik (i desítek) giga a proudové zpracování je jediné smysluplné.
BTW. Načítat celý zpracovávaný soubor do paměti může bez patřičných kontrol docela překvapit.
Drive se s oblibou pouzival shar - coz byl self extracting archive format.
prvnich par desitek radek byl nejaky script ktery se skutecne vykonaval a zbytek byl tar(cpio) archive ktery se extrahoval.
AWS (US-EAST-1) DynamoDB Outage report explained in plain English.
1. A race condition in DynamoDB’s DNS automation deleted its main endpoint record.
2. This happened when 2 DNS systems updated Route 53 at the same time and removed all IPs.
3. DynamoDB went offline, and services that depend on it like EC2, Lambda, Redshift, and IAM stopped working.
4. EC2 could not launch new instances because it uses DynamoDB to track server state.
5. Network and Load Balancer systems failed next, causing connection errors across AWS.
6. Engineers fixed the DNS issue, full recovery took about 15 hours.
If you are a DevOps or Cloud Engineer, this is a great use case to understand.
A small DNS automation glitch can bring half the internet down.
V Cloudu ma kazda sluzba vlastni sit a CIDR rozsahem, ktery nemusi byt unikatni.
Private endpoint je IPcko ve vasi siti, ktere reprezentuje sluzbu z jine site. Je to IPcko pres ktere se NATuje pristup k jine sluzbe. V tomhle prepade to byla IPcka DNS serveru.
Jak se zda tak v jednu dobu bezely dva terraformy, ktere nejak manipulovaly s temi endpointy a vysledkem te operace bylo, ze vsechny DNS endpointy byly smazany.
Neni to tak davno co si nejaka firma odpalila DNS a pak zjistila, ze bez DNS nefunguje AD (v prepade AWS IAM) a bez access managementu se neda DNS opravit.
Není potřeba si vymýšlet, co se stalo. Ve zprávičce je odkaz na post-mortem analýzu od Amazonu, kde je to podrobně popsané.
To nic neni, ale ted si predstavte, ze mate postel za 3k USD, platite predplatne 200 $ / rok - a postel vam zacne topit, piskat, nebo nejde sklopit a nejde na ni spat, muste ji odpojit od elektriny, protoze vypadlo AWS a ona je tak dobre napsana, ze se z toho zblaznila ;-)
Postel jeste vytahnete ze zasuvky.. ale v rodine se stalo ze privreli auto vratama od garaze. A ted to ma false readingy na znacky a buhvi co a neda se s tim jezdit protoze to keca velice nevybiravym zpusobem do rizeni :D (mozna na asistencni systemy je pojistka.. ale zatim to vypada na odtah.. pritom takova pitomost).
Ona ta blbost začíná už uraženým zrcatkem. Topný tělíska, serva zrcátka, kamera a osvětlení prahu. To vše je v háji. A po montáži nakalibrovat bird view.
To je postel pro techniky AWS :-D Za nás stačila SMSka z NAGIOSu, oni se asi chtějí probouzet jinak :-D