Hlavní navigace

Vlákno názorů k článku Nebojte se systemd: jednotky od BS - Zdravím, Problém je, že skript /etc/init.d/jmeno se musel pro...

  • Článek je starý, nové názory již nelze přidávat.
  • 2. 6. 2016 19:04

    BS (neregistrovaný)

    Zdravím,

    Problém je, že skript /etc/init.d/jmeno se musel pro každého démona vytvářet znovu.

    Tohle mi stále uniká. Za prvé snad stále musím napsat unit file a to pro každého daemona znovu, což je naprostá maličkost, ale za druhé v jakémkoli složitějším (čti produkčním) případě stejně bude nevyhnutelně třeba samotné daemony owrappovat nějakým skriptem, který doladí detaily.

    Napíši tedy skript, který bude mít třeba argument start a stop a ten pak uvedu do příslušných parametrů unit file, kam přidám ještě závislosti, podobně jako v LSB hlavičce init skriptu. Dohromady tedy napíši klasický init skript, ale místo jeho hlavičky někde bokem vytvořím unit file. To ale přece znamená, že jsem si nijak nepomohl, práce mi to tedy připadá úplně stejně.

    Samozřejmě po nějaké mpd to bez wrapperu asi půjde, ale to je jednoznačně desktopová věc a na desktopu uživatel běžně init řešit nemusí, ať má ten, či onen, já jsem až na naprosté výjimky nikdy nic takového dělat nemusel. Z druhého pohledu, mé zkušenosti s vývojem jak embed zařízení, tak serverových aplikací (skutečně daemonů, žádný web) naznačují, že skriptování se vývojář (jistě nikoli uživatel) nikdy nevyhne.

    Možná, že systemd má nějaké výhody proti sysv-init, ale výše uvedené tvrzení je podle mě skutečně nesmysl.

  • 2. 6. 2016 19:35

    Filip Jirsák

    Za prvé snad stále musím napsat unit file a to pro každého daemona znovu
    Je rozdíl mezi tím napsat skript v turingovsky úplném jazyce, který může dělat cokoli – a napsat konfigurační soubor.

    stejně bude nevyhnutelně třeba samotné daemony owrappovat nějakým skriptem
    Proč? Co by ten skript dělal?

  • 2. 6. 2016 22:51

    Kiwi (neregistrovaný)

    No právě. Že mám k disposici turingovsky úplný jazyk považuji za obrovskou výhodu. Občas se to totiž může hodit a v takovém případě se díky tomu dá elegantně vyřešit problém, který by byl jinak obtížně řešitelný nebo neřešitelný.
    Ale to je problém celého systemd a všech jeho zastánců - příliš mnoho toho ještě nepochopili, ale mají pocit, že vše dokonale chápou. Opravdu nechápu, co je vede směrem, kterým se kdysi vydaly Windows, když je evidentní, že to byla slepá ulička.
    Někteří lidé by asi opravdu měli zůstat u Windows a nepokoušet se programovat Linux, nebo ještě lépe - nepokoušet se programovat vůbec.

    Když Poettering zkouší vylepšovat Unix, je to podobné, jako by se Justin Bieber pokoušel vylepšovat Mozarta.

  • 3. 6. 2016 6:59

    Filip Jirsák

    Že mám k disposici turingovsky úplný jazyk považuji za obrovskou výhodu.
    Ne, vy ho nemáte k dispozici. Vám nezbývá nic jiného, než ho použít. K dispozici ho máte v systemd – ale ve většině případů ho použít nepotřebujete.

    Ale to je problém celého systemd a všech jeho zastánců - příliš mnoho toho ještě nepochopili, ale mají pocit, že vše dokonale chápou.
    No já nevím. Váš komentář v části týkající se porovnání systemd s jinými inity obsahuje dvě chyby. Odpůrci systemd jeho neznalost prezentují v každém druhém komentáři. Byl bych opatrný v hodnocení toho, kdo co nepochopil.

  • 3. 6. 2016 8:27

    Heron

    Vám nezbývá nic jiného, než ho použít.

    Ano, přičemž celý ten turingovsky úplný aparát musíte nutně použít, v žádném případě v bash skriptu nelze přiřadit jen hodnotu do proměnné. Jasně. Prostě se to musí nutně používat v celé turingovské komplexnosti...

    Mě se "líbí" (kdyby někdo nepoznal: ironie), jak se to dostalo do roviny urážek.

    Název článku projistotu rovnou obsahuje slovo "nebojte", aby se toto vyřídilo hned v nadpisu a v diskusi padají slova jako nechápou, nepořádek apod.

    Takže NetworkManager (viz minulá diskuse) nefunguje nikoliv proto, že jeho autoři jsou neschopní, případně nevěděli, do jak velkého úkolu se pouští, ale proto, že starý způsob nastavení sítě je nepořádek (nepořádek pro koho? Možná pro autory NM, ti se v tom nevyznají.). Aha. Takže starý způsob, který roky fungoval se označí slovem nepořádek jen proto, že někdo nedokáže napsat jeho náhradu. Super.

    Teď se tady opakuje slovo neznalost a nepochopení. Problém je, a bylo to vidět i v bugreportech ohledně zavedení KillUserProces­s=yes, že systemd nelze znát. Někdo to tam napsal správně. Nikdo nečte všechny changelogy i kdyby ano, i kdyby znal intimně verzi 229 a měl naučené všechny man stránky z paměti, tak je mu to stejně na nic, protože ve verzi 230 mu to stejně přestane fungovat. Při tomto způsobu vývoje ani není možné systemd znát.

    Mimochodem doteď jsem se nedozvěděl od lidí,kteří systemd chápou, rozumí mu a nebojí se ho, žádné řešení (já jsem navrhl 3).

  • 3. 6. 2016 8:44

    Filip Jirsák

    Ano, přičemž celý ten turingovsky úplný aparát musíte nutně použít, v žádném případě v bash skriptu nelze přiřadit jen hodnotu do proměnné. Jasně. Prostě se to musí nutně používat v celé turingovské komplexnosti...
    Zdá se, že nechápete, v čem je ten problém. Problém není v tom, že nějaké konstrukce bashe můžete použít. Problém je v tom, že nedokážete zabránit tomu, aby je někdo použil, problém je v tom, že to, zda jsou nebo nejsou použité, zjistíte jedině tak, že ten skript otevřete a celý ho přečtete.

    Takže starý způsob, který roky fungoval se označí slovem nepořádek jen proto, že někdo nedokáže napsat jeho náhradu.
    To někomu podsouváte svůj vlastí argument a zaměňujete příčinu a následek. Někdo nechce psát plnohodnotnou náhradu nepořádku, protože plnohodnotná náhrada nepořádku je zase jen nepořádek.

    systemd nelze znát
    Porovnáváte jeden systém, který je ve vývoji, se systémem, který se v základu nezměnil už hodně dlouho, a na něm je zbastleno spousta individuálních řešení. Výsledek je v současné době stejný – konkrétní řešení nelze znát. Výhoda systemd je v tom, že směřuje ke stavu, kdy ho bude možné znát, a jeho znalost použijete na kterémkoli systému. Na rozdíl od těch současných „řešení“, kdy sice můžete znát jednu konkrétní (nejlépe svou) instalaci, ale když přijdete jinam, můžete akorát hádat.

  • 3. 6. 2016 9:22

    Heron

    Problém je v tom, že nedokážete zabránit tomu, aby je někdo použil, problém je v tom, že to, zda jsou nebo nejsou použité, zjistíte jedině tak, že ten skript otevřete a celý ho přečtete.

    Já to za problém nepovažuji. Navíc historie ukazuje, že ty skripty jsou mnohem stabilnější co do chování, než systemd. Takže ano, v bashi může kdokoliv napsat cokoliv, to je pravda, ale v praxi se ukázalo, že tam píše jen to, co je nutné pro běh jeho služby (tzn daemonizace nějakého programu).

    Někdo nechce psát plnohodnotnou náhradu nepořádku, protože plnohodnotná náhrada nepořádku je zase jen nepořádek.

    Pokud někdo nechce psát plnohodnotnou náhradu něčeho staršího, tak to nutně skončí tak, že napíše neplnohodnotnou náhradu a pro stavy, kde tato náhrada nepůjde použít (na rozdíl od staršího řešení), to zase někdo bude muset nabastlit nějakým skriptem nebo něčím. Takže opět vznikne nepořádek.

    Potom klasicky opět přijde někdo, kdo to označí za nepořádek a protože opět nepochopí, v čem je problém, tak napíše ještě méně kompletní verzi a bude se to bastlit ještě víc. Takže zatímco na začátku jsou utilitky slepené turingovsky úplným lepidlem, tak na konci jsou utilitky, které toho umí ještě míň, jsou opět spojeny tu lepidlem. Gratulujeme.

    Porovnáváte jeden systém, který je ve vývoji, se systémem, který se v základu nezměnil už hodně dlouho, a na něm je zbastleno spousta individuálních řešení.

    Ne neporovnávám. Jestli něco porovnávám, tak je to systemd verze 229 a systemd verze 230, kde proběhla zcela zásadní změna koncepce formou jednoho odstavce v changelogu. I kdyby někdo měl krásně funkční systém postavený na 229, tak mu to ve 230 prostě nebude fungovat.

    Takové změny se obvykle řeší tak, že se nějaké staré řešení označí za deprecated, do logu, nebo na stderr, nebo při spuštění, nebo na jiné vhodné místo se dá upozornění, a po nějaké době se to přepne. Chovají se tak všechny příčetné systémy. Ne, že se to změní z verze na verzi a do bugzilly kompletně nesouvisejících projektů se napíše bug opravte si, co jsme my rozbili.

  • 3. 6. 2016 9:35

    Filip Jirsák

    Pokud někdo nechce psát plnohodnotnou náhradu něčeho staršího, tak to nutně skončí tak, že napíše neplnohodnotnou náhradu a pro stavy, kde tato náhrada nepůjde použít (na rozdíl od staršího řešení), to zase někdo bude muset nabastlit nějakým skriptem nebo něčím. Takže opět vznikne nepořádek.
    Nikoli. Ta náhrada obvykle poskytuje nové funkce. Stavy, kde náhrada nejde bezezměny použít, jsou (pokud ta náhrada je rozumná) hacky hacků – a náhrada pro danou věc poskytuje čisté řešení, bez hacků. Takže jediný „problém“ je ten, že je potřeba ty původní hacky zahodit a udělat to novým způsobem a pořádně. Skutečným problémem je pak to, že někdo trvá na použití těch hacků, pokouší se vyrobit hack hacku hacku a rozčiluje se, že mu to nejde. V jiné oblasti to vidíme třeba při přechodu na IPv6, kdy je taky spousta „administrátorů“ celá nesvá z toho, že najednou mají veřejných IP adres, kolik chtějí, a pořád se snaží někam naroubovat NAT a šetřit IP adresy, protože jsou na tyhle hacky zvyklí.

    staré řešení označí za deprecated
    To by mne zajímalo, jak chcete označit jako deprecated defaultní hodnotu konfigurační volby.

  • 3. 6. 2016 9:54

    Heron

    a udělat to novým způsobem a pořádně

    Fajn, zpět k systemd, je někde popis, jak to udělat novým způsobem a pořádně a tak, aby to přežilo změnu verze 229 a 230?

    Když přijde junior, chytrý, inteligentní člověk světem serverů nepolíbený, odkud podle tebe má začít?

    Tohle totiž nikde není. systemd jede změnu za změnou salámovou metodou a není možné se připravit na budoucí verze. Celé to působí dojmem, že ani autoři nevědí, kam jedou.

    To by mne zajímalo, jak chcete označit jako deprecated defaultní hodnotu konfigurační volby.

    Tak především se ta defaultní hodnota změnila. V 229 byla no, v 230 je nově yes.

    Tohle na první pohled nevinné přepnutí způsobuje to, že věci, které fungovaly 30 let náhle fungovat přestávají. Ano, jedno ze 3 řešení je přepnout si to zpět na no. Ale asi to není ta správná systemd way, protože jinak by ten default neměnili. Jen vůbec není jasné, jaké je to správné nové řešení.

    Za druhé, to si z nás opět děláš srandu, že? Za těch 15 let jsem mnohokrát na různých místech (při update balíčku, při bootu, při spuštění služby, v logu, na stderr, prostě všude) viděl různá varování: pozor, toto je deprecated a změní se to, upravte si to. Je to zcela běžné.

  • 3. 6. 2016 10:19

    Filip Jirsák

    Tak především se ta defaultní hodnota změnila. V 229 byla no, v 230 je nově yes.
    Ano. A vy jste psal, že ve verzi 230 měla být výchozí hodnota no označena jako deprecated, a někdy později teprve změněna na yes. A já se ptám, jak konkrétně se to mělo udělat. Měla se do systemd přidat funkcionalita, že se u každé volby bude sledovat, odkud pochází, a pokud pochází z v výchozí konfigurace a je no, mělo se vypsat varování? Nebo se varování mělo vypisovat pořád, bez ohledu na nějakou konfiguraci? Srandu si nedělám, zcela vážně jsem se ptal na to, kdy přesně by se to varování mělo zobrazovat, a svůj dotaz tímto opakuju.

  • 3. 6. 2016 10:25

    Heron

    A vy jste psal, že ve verzi 230 měla být výchozí hodnota no označena jako deprecated

    Nic takového jsem nepsal.

    Srandu si nedělám, zcela vážně jsem se ptal na to, kdy přesně by se to varování mělo zobrazovat, a svůj dotaz tímto opakuju.

    Můj návrh: od verze 200, nebo lépe 150, se mělo zobrazovat upozornění: pozor, chystáme se na velkou změnu koncepce, je možné, že vám některé věci přestanou fungovat. Popis změny a doporučený postup naleznete v man systemd_future, případně na webu.

  • 3. 6. 2016 8:36

    BS (neregistrovaný)

    Napsání unit file je samozřejmě naprostá maličkost, to nikdo nezpochybňuje. A co by ten skript dělal? Tak třeba primitivní příklad ze života. Představte si službu, která běží na na embed zařízení v rámci své inicializace potřebuje přečíst několik parametrů z integrované EEPROM. A teď si představte, že máte více typů těchto zařízení, ale ty mají různé procesory a EEPROM je na každém připojena trochu jinak.

    Takže mám tři možnosti, buď do služby přímo implementuji schopnost číst všechny typy, nebo vytvořím pro každý HW vlastní verzi, což je dost neudržovatelné a nebo pro každý HW napíšu skript, který údaje přečte a službě předá jako argument. Třetí varianta je nejsnazší, je sice třeba udržovat skripty, ale není potřeba nepřetržitě modifikovat zdrojové kódy (třeba C) služby. Navíc je také možné, že služba je nějaký OSS, který se vyvíjí a bylo by nutné vždy novou verzi patchovat, takže přímá modifikace služby je dost komplikované řešení, proti eleganci skriptu.

    Ty skripty slouží jako glue, který lepí danou službu s konkrétním nasazením, svět Linuxu není jen x86/amd64 s Gnome/KDE. Naopak ty desktopy jejichž HW má ve srovnání se zbytkem zařízení v podstatě normované chování jsou naprostá minorita. Také je naprosto správně, že programátoři neimplementují každou možnou nuanci do binárky nebo do konfigurace, ale očekávají, že tyto nuance se vyřeší skriptem. Není ani nic nezvyklého, že konfigurace daemona se vytvoří až ve skriptu, podle nějakého templatu.

  • 3. 6. 2016 8:52

    Filip Jirsák

    Aha, takže ve skutečností žádný wrapper pro spuštění nepotřebujete. Potřebujete buď nástroj, kterým vytvoříte předem konfiguraci pro dané zařízení (pokud se nemůže měnit), a nebo potřebujete nástroj, který spustíte před vlastní službou, který zjistí příslušné parametry a službu před jejím spuštěním nakonfiguruje.

    Vidíte, ve vašem řešení se obalujícím skriptem byste to slepil všechno dohromady a následně by se to špatně udržovalo. Systemd vás vede k tomu, abyste oddělil službu a její konfiguraci, takže to pak můžete spravovat i aktualizovat každé zvlášť.

  • 3. 6. 2016 9:35

    BS (neregistrovaný)

    Pokud jde o udržování rozdíl nevidím, v obou případech je někde nějaký skript, který je potřeba udržovat. Pokud jde čistě o vygenerování konfigurace, máte pravdu, že je velmi elegantní použít samostatnou službu, které se o to postará (ta služba je skript), toto často při vývoji používám bez ohledu na init systém. Pokud, jde ale pouze o to předat dva argumenty začne to dle mého ztrácet přehlednost.

    Konfigurační služba by vytvořila předpis pro spuštění druhé. Tento předpis by mohl být buď přímo unit file, nebo jednořádkový skript, který by předem udělaný unit file spustil, což mi připadá ekvivalentní, ale zdá se mi to jako jít kanónem na vrabce.

    Nicméně mě neberte jako apriorního odpůrce systemd, já si více méně myslím, že za pár let, až se stabilizuje API, bude mít linuxovému světu hodně co nabídnou. Poukazuji pouze na to, že absence skriptování je utopie. Jak vidíte, tak jak v mém tak ve vašem řešení se ten skript objevuje, jde jen o to kdy a kde se spustí, což je konec konců kosmetické, někdo ho totiž stejně musí napsat.

    Sys-V init má spoustu nedostatků, o tom není pochyb, ale skriptování k nim nepatří, to je naopak největší přednost, právě díky univerzalitě, kterou tento přístup nabízí, se udržel tak dlouho i přes své nedostatky. Konec konců, třeba ten Debian také používá systemd převážně jako spouštěč LSB init skriptů a řekl bych, že jiné distribuce jsou na to podobně.

  • 3. 6. 2016 9:52

    Filip Jirsák

    Univerzálnost je dobrý sluha, ale zlý pán :-) Systemd umožňuje použít skripty, pokud je to potřeba – ale pro většinu věcí to potřeba není, a nakonec dosáhnete lepšího výsledku jednodušším konfiguračním souborem. všechno, co můžete udělat v systemd, můžete udělat i v univerzálním skriptu – akorát zkušenost ukazuje, že se tak neděje.

  • 3. 6. 2016 13:00

    Jan (neregistrovaný)

    To se říká o ohni. Ale vzdávat se ho kvůli tomu nebudeme. Má nás to jen upozornit, abychom si při jeho využívání dávali pozor. A v tomto případě to má být zrovna tak.