Doplním takový příběh k .device a .mount a o tom, jak je "hrozně užitečné" mít automatické akce při aktivaci nějakého zařízení.
Selhal hw řadič na kterém byla 1/3 disků z R10 (mdadm). Bohužel zrovna celé jedno zrcadlo. mdadm stihl na zbývající disky ještě něco zapsat (a poslal tak fs do kytek). Mno ale o tom tento příběh není.
Po profackování řadiče se tento při spuštění znovu objevil i s disky. mdadm se odmítl sestavit, prostě proto, že mu neseděla data a neměl dostatek disků. Do této chvíle je vše v pořádku.
Byl čas, chtěl jsem si s tím hrát, data byla na zálohách (v žádném případě nebylo v úmyslu používat data na tomto zbořeném poli), takže o nic nešlo. Sestavil jsem mdadm -A --force s tím, že s tím pro efekt zkusím něco udělat (třeba to blokové zařízení jako celek někam zkopírovat a dál si s tím hrát).
Jenže, co se nestalo. Systemd zjistil, že se mu tam objevilo nějaké device a neměl vůbec nic lepšího na práci, než to začít připojovat (nejdřív fsck, potom mount). Jenže fsck je by default nastaven tak, aby automaticky prováděl "bezpečné opravy" (což je dost relativní). Takže na ten block device zapsal, čímž se veškeré pokusy o opravu omezily na tento jeden pokus...
Tož tak. Je prostě "hrozně fajn", kdy neustále něco hrabe adminovi pod rukama. To se potom dobře pracuje.
Čistě náhodou má, ale to nebylo jádrem sdělení mého komentáře.
Když se v systému objeví nějaké nové block device, tak jako admin nepředpokládám, že se mi do toho něco začne automaticky hrabat a zapisovat na to. (Evidentně se doba mění, takže to dopadne jak ve Widlích, kde systém detekuje nové block device a hned začnou vyskakovat hlášky o inicializaci (vytvoření gpt/mbr) apod.)
To Palo: Nejen zakomentovat ve fstabu, ale také reloadnout systemd:
systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded. This will instantiate mount and swap units as necessary.
Kdyz vybehly win8, myslel jsem, ze az win7 skonci, vratim se k unixu.
Mezitim se ale do debianu dostal systemd, a zmenil u*x OS na generator nahodnych (a nechtenych) stavu.
Tak holt asi zkusim ty win10 :-(
Proc jde svc v solaris udelat jednou a dobre, zatimco systemd programuje arogance s neznalosti, bez ohledu na kontinuitu, jak se zrovna ten ktery den vyspi ?
Bohužel v případě systemd často správce řekl systému, co se má stát, způsobem který léta fungoval. Protože ten způsob léta fungoval tak se našel někdo kdo do systemd nabastlil emulaci toho způsobu, která bohužel často dělá jen "základní" emulaci - tedy interpretuje to co správce nastavil špatně. Takže na administrátora ani při upgradu nebo reinstalaci systému nevypadne varování, že používá ve skutečnosti nepodporovaný postup, ale místo toho mu to pod rukama potichu rozbíjí systém.
To je způsobeno tím, že systemd je revoluce, nikoli evoluce. Spousta chyb, která se za léta odladila, se bude vyskytovat znovu a budou se znovu ladit, tak jak se na "kompletní refaktor" sluší a patří.
Což je důsledek té snahy o zpětnou kompatibilitu, kterou tady mnozí vyžadují.
Výhodou toho kompletního refaktoru je to, že se ty chyby odladí už jen jednou a nebudou se vynořovat znovu a znovu s každým přidáním nové komponenty.
Mně by se taky mnohem víc líbilo, kdyby se správa služeb v Linuxu opravila evolučním způsobem, ale podle mne je to v současném stavu už nemožné, těch vrstev různých hacků je na sobě už příliš.
Kompatibilní se sebou je systemd tak, že novější verze přečte starší nastavení.
Chování mezi verzemi mění kde co. Od jádra počínaje až po ten screen.
Pro tupce Stena .... visi mi tu trebas upgrade apache 2.2 -> 2.4 ... to ze je treba prepsat (lehce) konfiguraci se vi ... chmm od doby vydani 2.4, coz je slusnych par patku zpet. Distro na to jeste extra upozornuje a ... NIC mi nebrani vesele dal pouzivat 2.2 ... dokud si nenajdu cas. Mam na to ... ROKY.
Kupodivu mi kvuli tomu ani neprestane fungovat sit, ani se mi neposere logovani, ani mi neprestane fungovat dns/dhcp/ntp/... protoze ... to s tim NIJAK nesouvisi.
Ale tohle neni aktualizace, to je upgrade, v ramci jednotlivych revizi se NIC nemeni.
Zato v systemd se meni COKOLI KDYKOLI a JAKKOLI. A kdyz to obratem nepatchnes, zhrouti se libovolna soucast systemu.
Chování Apache se mění poměrně často. Že se to neprojeví u tebe, je proto, že distribuce ty změny odkládají (upravují), třeba v Debianu má poslední Apache 2.2 49 patchů, z nichž alespoň 5 mění výchozí nastavení či kompilační volby. Překvapení, co? Systemd v tomhle není výjimka a Debian si samozřejmě hlídá.
Systemd tě taky nijak nenutí něco aktualizovat. Změny chování při aktualizaci distribuce dokumentují u systemd úplně stejně jako u toho Apache. Systemd ti dokonce nebrání dál vesele používat ten Linux z roku 1995, dokud si nenajdeš čas se naučit, jak funguje PAM.
Je mimochodem zajímavý, jak ty bez systemd víš úplně přesně, jak by to nám, kteří systemd používáme, vlastně vůbec nemělo fungovat. Asi hodně kvalitní křišťálová koule. Nebo LSD.
Změnilo se jen to, co se stane, pokud nějaké nastavení neuvedete. Což je naprosto normální pro všechen software, od jádra až po ten screen.
Aha. Tak me se az dosud zdalo, ze veci mivaji nejake defaulty, ktere maji tendenci drzet napric verzemi a meni se jen vzacne, pokud vubec. V systemd se ale meni jaksi nahodne a bez toho, ze by se nekdo zamyslel a otestoval, co se tim posere. Defaulty nyni asi zalezi na tom, jak se Poettering vyspinkal.
Ano, ale urcite je vhodne rozlisovat akce na akce, ktere se maji provadet pouze jednou behem startu systemu a na ty, ktere se mohou provest kdykoliv behem behu systemu. Zatim systemd neznam, ale toto by se mi libilo... jde o to mit tu moznost.
U stareho dobreho fstabu a initu ruznych znacek se dala pouzit kombinace voleb auto, noauto, nofail, _netdev a docilit tak konzistentnich a bezpecnych stavu.
Ano, ale urcite je vhodne rozlisovat akce na akce, ktere se maji provadet pouze jednou behem startu systemu a na ty, ktere se mohou provest kdykoliv behem behu systemu. Zatim systemd neznam, ale toto by se mi libilo... jde o to mit tu moznost.
U stareho dobreho fstabu a initu ruznych znacek se dala pouzit kombinace voleb auto, noauto, nofail, _netdev a docilit tak konzistentnich a bezpecnych stavu.
sorry, asi buga v redakcnim systemu, protoze jsem se dvakrat snazil odpovedet na https://www.root.cz/clanky/nebojte-se-systemd-zbyvajici-typy-jednotek/nazory/881439/ a po kazde to tu odpoved zaradilo spatne...
OT: btw. jak se pote, co odpovim na neco v diskuzi, zase jednoduse vratim, tam kde jsem byl pred tim
To je ale úplně jedno.
Standardně to vždy probíhalo tak, že pokud při bootu nějaké device (definované v fstab) chybělo, rc systém se s tím nějakým způsobem ne/vypořádal (recovery mod apod.), ale především, automatické mountování na základě fstabu se uplatňoval pouze při bootu (alespoň ve všech mě známých distribucích), takže když se později dané zařízení objevilo (po nějakém zásahu admina), tak se nestalo vůbec nic a admin si sám rozhodl, co s tím udělá.
Tohle je další a velmi podstatná změna chování systému.
Ano, je skoda, ze nepise v C#, aby kazdy hned videl, ze je to silenec.
Jinak nevim, jak chcete Poetteringa donutit ke spolupraci. To leda, ze by nekde ukradl prase, vy jste mel dukazy a mohl ho vydirat. Poettering nekomunikuje, kritiku ignoruje ci odmita a jako bozstvo ze sveho Olympu milostive diktuje, co se vam ma libit. Poettering jiz dostatecne dokazal, ze neni tymovy clovek, ale ze je systematicky rozbijec, ktery se opira o vahu Red Hatu. Nebyt toho, nikdo se s nim nebavil a systemd by skoncil nekde v galerii opravdu spatnych napadu.
Rad by som pripomenul fakt, ktory je podla mojho nazoru velmi dolezity, ale vo Vasom prispevku nie je vobec spomenuty. Ide o to, ze systemd pouziva zariadenie iba v pripade, ze je explicitne oznacene tagom :systemd: v udev databaze a prislusna udev udalost ma nastaveny kluc SYSTEMD_READY=1. Typicky priklad pouzitia SYSTEMD_READY=0, i.e. storage subsystem oznamuje systemd, ze s danym blokovym zariadenim nema zatial pracovat, je v LVM udev pravidlach.
Myslim, si ze Vasa situacia je mozno hodna bug reportu proti mdadm. Pravdepodobne by to chcelo nejaku zmenu v mdadm udev pravidlach, aby pole ktore bolo zlozene s --force bolo oznacene ako SYSTEMD_READY=0. systemd potom nezacne mountovat filesystem.
Je mozne, ze je nieco rozbite v systemd vzhladom k problemu ktory popisal Heron. Ja si skor myslim, ze je problem v mdadm udev pravidlach kedy je nespravne oznacene ako pouzitelne zariadenie s ktorym je nejaky problem.
To ze systemd reaguje dynamicky na udalosti v systeme ako napriklad pridanie alebo odstranenie blokoveho zariadenia je vyznacna vlastnost systemd, ktorou sa odlisuje prave od SysVInit. IIRC, Heronov fstab zaznam neobsahoval noauto a teda systemd sa snazilo pripojit dany suborovy system automaticky potom ako sa objavilo potrebne diskove zariadenie. Ako som uz spominal, to ze sa objavilo nie je problem, ale ze bolo pravdepodobne chybne oznacene za pripravene pre pouzitie.
Je mozne, ze je nieco rozbite v systemd vzhladom k problemu ktory popisal Heron. Ja si skor myslim, ze je problem v mdadm udev pravidlach kedy je nespravne oznacene ako pouzitelne zariadenie s ktorym je nejaky problem.
Fascinující. Upřímně řečeno, psal jsem to spíš jako upozornění pro ostatní, co vše se může stát a mezitím se tady v diskusi probírá už pomalu půlka systémových komponent. Prostě fascinující.
Dřív na to stačilo jedno zařízení v /dev s major minor, a jeden mount.
Ale to nebylo dost moderne khulloidni ... a navic to proste a bez kecu fungovalo. Hele, mam tu par krabek, ve kterejch mam statickej dev ... proste co si tam dam to tam je a nazdar bazar. A je to parada, nikde se mi do niceho nesere udev a jeho neustaly objevovani se a mizeni veci.