abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 01:11 | Nová verze

    Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.

    Ladislav Hagara | Komentářů: 0
    dnes 00:55 | Nová verze

    Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    včera 22:55 | Nová verze

    Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.

    Ladislav Hagara | Komentářů: 0
    včera 22:33 | IT novinky

    Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.

    Ladislav Hagara | Komentářů: 1
    včera 18:33 | IT novinky

    Ultra Ethernet Consortium (UEC), jehož cílem je optimalizace a další vývoj Ethernetu s důrazem na rostoucí síťové požadavky AI a HPC, vydalo specifikaci Ultra Ethernet 1.0 (pdf, YouTube).

    Ladislav Hagara | Komentářů: 0
    včera 13:00 | IT novinky

    Francouzský prezident Emmanuel Macron chce zakázat přístup na sociální sítě pro děti do 15 let. Francie podle něj tento krok udělá sama do několika měsíců, i pokud se na něm neshodnou další státy Evropské unie. Reaguje tak na úterní vraždu vychovatelky, kterou ve východofrancouzském městě Nogent pobodal 14letý mladík. Jednotlivé sociální sítě podle něj mají možnost věk ověřit a vymáhat zákaz pomocí systémů na rozpoznávání tváří.

    Ladislav Hagara | Komentářů: 8
    včera 05:11 | IT novinky

    Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.

    Ladislav Hagara | Komentářů: 0
    10.6. 22:33 | Nová verze

    Oficiálně byl vydán Android 16. Detaily na blogu a stránkách věnovaných vývojářům.

    Ladislav Hagara | Komentářů: 3
    10.6. 14:33 | Nová verze

    Byla vydána nová verze 14.3 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    10.6. 14:00 | Upozornění

    CSIRT.CZ upozorňuje, že na základě rozhodnutí federálního soudu ve Spojených státech budou veškeré konverzace uživatelů s ChatGPT uchovávány. Včetně těch smazaných.

    Ladislav Hagara | Komentářů: 14
    Jaký je váš oblíbený skriptovací jazyk?
     (56%)
     (31%)
     (7%)
     (2%)
     (0%)
     (0%)
     (3%)
    Celkem 249 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení

    6. 10. 2014 | Tadeáš Pelech | Jaderné noviny | 3530×

    Aktuální verze vývojového jádra: 3.17-rc4. Citát týdne. Pomalé zjišťování + udev + SIGKILL = problémy.

    Obsah

    Aktuální verze vývojového jádra: 3.17-rc4

    link

    Vývojové jádro 3.17-rc4 vyšlo dne 7. září (oznámení). po týdnu, který byl, alespoň ke konci, podle Linuse „celkem normální“. Linus k tomu řekl:

    Celkem normální docela ujde a já si nestěžuju. Neděje se nic zvlášť velkého ani hrozného – na chvíli nás vyděsila hloupá chyba ve vrstvě kompatibility, ale zdá se, že šlo jen o planý poplach, který vyústil spíš v přidání nějakého komentáře než ve změny ve zdrojovém kódu.

    Stabilní aktualizace: 5. září byly vydány verze 3.16.2 (oznámení), 3.14.18 (oznámení) a 3.10.54 (oznámení). Nedodělky v implementaci oprav jsou momentálně údajně velké, v dohledné době tedy čekejte víc (větších) aktualizací.

    Citát týdne

    link

    - .set_mux = pcs_sex_mux,
    + .set_mux = pcs_set_mux,

    Linus Walleij (odkaz) opravil „freudovské přeřeknutí“ (díky Jonu Mastersovi)

    Pomalé zjišťování + udev + SIGKILL = problémy

    link

    Před pár lety se vývojáři jádra krátce pokoušeli převést veškeré zjišťování zařízení na asynchronní činnost. To vedlo ke komplikacím, které byly natolik obtížně řešitelné, aby byly tyto snahy označeny za neperspektivní a všechny změny byly vráceny. Nyní se asynchronní zjišťování vrátilo na pořad jednání. Tato myšlenka se nesetkává s obecně pozitivním přijetím, ale problém, který se snaží řešit, je skutečný. A poněkud podivný.

    Všechno začalo v listopadu 2013, kdy Tetsuo Handa napsal opravu, která umožňuje násilně ukončit funkci jádra kthread_create(), která vytváří a spouští vlákno jádra (tedy, že je ukončena signálem SIGKILL). Před touto změnou byl jakýkoli proces spuštěný ve funkci kthread_create() dočasně imunní k signálu SIGKILL, konkrétně nereagoval, pokud ukončovací proces OOM (vyčerpání paměti) vyhodnotil, že je toto ukončení nutné. I když se dá nesouhlasit s heuristikou, podle které tento proces vybírá své oběti, jen málo vývojářů se domnívá, že by tyto oběti, když už jsou vybrané, měly v systému zůstávat po libovolnou dobu. S Tetsuovou změnou není proces, který způsobil vytvoření vlákna jádra, dále imunní před výpady ukončovacího procesu OOM.

    Tato oprava způsobila, že některé systému nebylo možné spustit. Spousta ovladačů úložných systémů vyžaduje k dokončení procesu zjišťování polí úložišť vlákna jádra. Tento postup zjišťování si může vyžádat velký objem práce, takže může běžet třeba i minutu. Podle všeho nemá systemd-udev neomezenou trpělivost; při načítání modulu zařízení spustí 30sekundový časovač (zkrácený z loňských 3 minut) a při překročení tohoto limitu proces načítání ukončí (signálem SIGKILL). Proces zjišťující pole úložišť je tedy ukončen, sestavení pole selže a systém se nespustí. Před Tetsuovou změnou byl tento signál při zjišťování ignorován; po ní se stal fatální. Tento problém se může dotknout i dalších typů ovladačů, které musejí stahoval velké firmwary.

    Výsledná diskuse se rozprostřela v několika diskusních fórech a systémech sledování chyb, takže ji bylo obtížné sledovat. Vývojáři jádra podle všeho sdíleli názor, že napevno nastavený 30sekundový limit v systemd-udev není dobrý nápad a že problém by se měl řešit zde. Vývojáři systemd se domnívají, že modul, který se načítá déle než 30 sekund, je zkrátka chybný a měl by se opravit. Tetsuo navrhl, že funkce kthread_create() by měla na signál SIGKILL reagovat se zpožděním 10 sekund, pokud příslušný signál pochází odjinud než ze správy OOM. Ani jeden z těchto návrhů nebyl obecně přijat ani nevedl k řešení problému.

    Existuje samozřejmě možnost prostého prodloužení časového limitu v konfiguračních souborech, jak to udělali vývojáři mapovače zařízení v reakci na obdobný problém. Tento přístup ale nikdo nepovažuje za příliš elegantní.

    Tento problém lze řešit ještě jinak – ovladače zařízení by se při spouštění mohly prostě registrovat a provádět činnosti, které lze rychle dokončit. Všechny časově náročné úlohy by se předávaly do samostatného vlákna spuštěného asynchronně, po načtení modulů a ukončení aktivity systemd-udev. Tento způsob asynchronní inicializace by navíc zlepšil dobu spouštění, protože by během pomalého zjišťování mohly probíhat další činnosti.

    V tom ohledu zveřejnil Luis Rodriguez sadu oprav, které do jádra ovladačů přidávají asynchronní zjišťování. Tyto opravy přidávají pole (async_probe) do struktury struct device_driver; pokud má toto pole hodnotu true, zjišťování zařízení bude probíhat asynchronně prostřednictvím pracovní fronty. Byly upraveny tři ovladače (pata_marvell, cxgb4 a mptsas) tak, aby požadovaly nový asynchronní přístup. Existuje také varianta Tetsuovy opravy s 10sekundovým zpožděním, která je primárně určena k zápisu upozornění do systémového žurnálu v případě, že správa OOM vydá signál SIGKILL funkci kthread_create(); má pomoci identifikovat další ovladače, které je nutné převést na asynchronní režim.

    Tejun Heo, který také spravuje vrstvu ATA, pro tento přístup není. Nakonec má námitky ke dvěma problémům:

    • Tento problém se potenciálně může projevit u všech ovladačů. Úpravy těch ovladačů, u kterých se problém vyskytne, je tedy špatným řešením – stále budou přibývat nové ovladače, které bude potřeba upravit.
    • Linuxové systémy vždycky stíhaly zpřístupnit lokálně připojená zařízení při dokončení načtení modulu. Přechod do asynchronního režimu je proto změna v chování, kterou uživatel zaznamená; může narušit správcovské skripty, které očekávají, že budou disková pole připravena k připojení bezprostředně po načtení ovladače.

    Druhý problém je kontroverznější. Moderní distribuce časovou posloupnost připojování zařízení k systému neřeší, proto někteří vývojáři namítají, že v téhle oblasti by už k žádným problémům docházet nemělo. Ale staré správcovské skripty se mohou zablokovat i na delší čas. Takže riziko narušení reálně fungujících systémů takovou změnou je skutečné, i když není jasné, kola systémů se může dotknout.

    Některé reálně používané systémy už jsou samozřejmě narušené nyní, proto by se s tím mělo něco dělat. Nejpravděpodobnějším výsledkem bude nějaké asynchronní zjišťování prováděné v uživatelském prostoru; pokud to uživatelský prostor nebude explicitně vyžadovat, toto chování by se nemělo měnit. Pravděpodobným uplatněním tohoto přístupu je globální příznak, který asynchronní zjišťování zapne, s jednou výjimkou. Existuje velká pravděpodobnost, že libovolný kód v jádru volající funkci request_module() očekává, že zařízení požadovaného modulu bude k dispozici po dokončení volání. Proto moduly načítané tímto způsobem by se – alespoň prozatím – měly načítat synchronně.

    U distribucí, kde správu polí úložišť řeší skripty dodané v distribuci, by měl být přepínač „použít asynchronní zjišťování“ standardně vždycky zapnutý. Ostatní budou vyžadovat nějaký manuální zásah. Není to nejlepší možné řešení, ale mohlo by být nejvhodnější v nejbližší budoucnosti.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    6.10.2014 10:07 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    Výsledná diskuse se rozprostřela po několika seznamech a sledování chyb

    Ty "seznamy" mají být mailing listy? A nemohlo by to být aspoň něco jako "systémy (pro) sledování chyb", aby k pochopení věty nebyl potřeba překlad zpátky do angličtiny?

    7.10.2014 17:47 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    Konspirační teorie: Luboš nemá čas překládat, tak publikuje pod falešným jménem něco, co má přesvědčit čtenáře, aby se někdo zdobrovolnil.
    Quando omni flunkus moritati
    xkucf03 avatar 6.10.2014 15:12 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    .set_mux = pcs_sex_mux,

    A tohle šlo zkompilovat? :-)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    6.10.2014 18:10 pavele
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení

    Podle všeho nemá systemd-udev neomezenou trpělivost; při načítání modulu zařízení spustí 30sekundový časovač (zkrácený z loňských 3 minut)...
    :-)

    6.10.2014 18:41 mankind_boost | skóre: 7 | Hliněná chýše, 5482/3
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    :-(
    Jen skutečný mankind_boost je zárukou kvality.
    pavlix avatar 6.10.2014 19:16 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    Je tam nějaká souvislost, která mi uniká?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    6.10.2014 20:43 pavele
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    1. Načítání modulu nefunguje -> Udělej přesný počet kliků -> Otoč se na SSV rychlostí přiměřenou -> Čekej přiměřený čas -> Pokračuj.

    2. Pokud to nefunguje, nechej to opravit jadernými vývojáři - jasná chyba jádra.

    To se v programátorské praxi běžně používají takové triky?
    7.10.2014 07:16 frr | skóre: 34
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Asynchronní detekce *všech* blokových zařízení - to je slovo do pranice :-)

    Zatím tohle fungovalo jenom na USB - kdo jste zkoušeli bastlit distro, které by bootovalo z USB CD nebo HDD, asi jste si všimli. Všimli jste si, že z toho nejde přímo mountovat root, protože USB disky v tu chvíli prostě ještě nejsou "nalezené" (trvá to dalších pár vteřin). Takže mountnout ramdisk a pak olizovat nějakým skriptem, kdy se to chytne (nebo čekat dlouhý pevný čas - fuj).

    Čili "asynchronní detekci" vnímám tak, že časem se tohle bude týkat mnoha direct-attached diskových médií. A nejde jenom o mountnutí root volume, jde obecně o celý fstab i jakékoli další svazky mountované jinými způsoby. V zásadě dneska spousta servisek (třeba Samba) při svém startu (init skriptem) považuje za samozřejmé, že jsou v okamžiku startu servisky mountnuté všechny svazky, které serviska potřebuje ke své práci. Pokud tenhle předpoklad přestane platit, je potřeba nějak navázat servisky na přítomnost namountovaných svazků... bude veselo :-) Vlastně na to stačí pár řádek, grepnout něco z výstupu "mount" apod. - nebo by to možná šlo nějak zajímavěji, mohl by se pro to zřídit nějaký systémový framework na bázi událostí, možná už dokonce existuje a jmenuje se udev...

    Třeba auto-fsck při startu to má ošetřeno tak, že dokud nedoběhnou všechny instance fsck, visí systém "v singlu", nezačne bootovat zbytek user space.

    Třeba přímo připojené HDD jsou ještě docela rychlé, ale nejsem si jist, zda by se detekce a inquiry stíhala asynchronně do okamžiku, kdy se jádro dostane do bodu "připraven mountnout root".

    Že se nestihne loadnout firmware a projít strom zařízení na nějakém větším DAS RAIDu nebo SAN síti, to mi přijde vcelku přirozené - a nemusí to trvat tři minuty, stačí pár vteřin a je vymalováno.

    Možná by kernel při mountování rootu nemusel házet hned panic, možná by mohl nějakou dobu čekat na "kýžený root volume". Ale jak říkám - to je jenom první překážka v řadě. Pravda je, že ty následující už žijí v user space.
    [:wq]
    7.10.2014 08:35 R
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Napad je to dobry - kym jeden driver caka napriklad na rozbehnutie diskov (to mozu byt desiatky sekund), takt dalsie mozu robit nejaku uzitocnu cinnost. Otazkou zostava, ako to bude fungovat v praxi.
    7.10.2014 08:46 Tom K | skóre: 22
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Otazkou hlavne zustava, jak se s vyporadat se stavem, kdy ten dalsi potrebuje prave ty roztocene disky. Cimz se dostavame k ekvivalentu serioveho a paralelniho initu, ale v mnohem komplikovanejsim kusu kodu, ktery obsahuje daleko vic zavislosti a musi fungovat spolehlive na mnoha platformach.

    On je rozdil si na tohle hrat v userspace, kde zjevne jen malo lidi trapi, ze nova vec (napr systemd) rozbije spoustu starych. A je rozdil udelat totez v kernelu, ktery nema povoleno nic rozbit (zkuste navrhnout, ze kernel v tuhle chvili omezi funkcionalitu nejake sve casti treba na tretinu jen proto, ze se to jednomu vyvojari zdalo fajn).

    V kernelu zatim asynchroni inicializace zarizeni neni, protoze v praxi prinasi vic problemu nez uzitku.
    echo -n "u48" | sha1sum | head -c3; echo
    7.10.2014 12:41 R
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Roztocene disky nepotrebuje v kerneli ziadny dalsi driver. Rovnako ako USB disky, ktore sa inicializuju v lubovolnom momente. Dalsie akcie sa vyvolaju ako nasledok toho, ze sa objavil disk.
    7.10.2014 15:14 ...
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    stejne blbe jako kdyz zarizeni zmizi a zase se objevi, protoze si kernel usmyslel, ze provede reset radice.
    7.10.2014 08:45 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    V zásadě dneska spousta servisek (třeba Samba) při svém startu (init skriptem) považuje za samozřejmé, že jsou v okamžiku startu servisky mountnuté všechny svazky, které serviska potřebuje ke své práci.
    Zrovna tohle je v systemd světě řešitelné velmi jednoduše: přidáš do unit souboru dotyčné služby tvrdou závislost na daném zařízení a je to.
    7.10.2014 10:21 mankind_boost | skóre: 7 | Hliněná chýše, 5482/3
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    +1
    Jen skutečný mankind_boost je zárukou kvality.
    7.10.2014 12:43 R
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Takze vsetky samba shary, ktore su namountovane particie, budu na troch miestach? fstab, smb.conf a este nejaky unit?
    8.10.2014 09:31 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Alternativou v sysv je fstab, smb.conf a samo domo skript, který by ti ohlídal, aby se samba spouštěla až po namontování dotyčných partišen... Aneb systemd tady není to, co ti nutí změnu, systemd ti umožňuje se změně kernelu popisované v TFA jednoduše přizpůsobit!
    7.10.2014 15:49 martian
    Rozbalit Rozbalit vše Re: asynchronní detekce/enumerace blokových zařízení
    Zrovna tohle je v systemd světě řešitelné velmi jednoduše
    Takze, az si to precita Lenart, bude uz len otazkou casu, kedy systemd integruje kernel. (Nakolko je velmi nepravdepodobne, ze by kernel integroval systemd.)

    A naschval sa nevyjadrujem, ci to bude dobre, alebo zle... Zacinat so systemd v jadernych novinach je zaruceny flamewar. Skoda, ze sa nepocitaju komentar "hits" ;-)
    7.10.2014 08:34 Honz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení
    Celkem normální docela ujde
    Tohle by asi chtělo trochu učesat...

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.