Vlákno názorů k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL? od VS - Přesně tento typ problémů je pro mě zásadním...
-
VS (neregistrovaný)
Přesně tento typ problémů je pro mě zásadním argumentem pro systemd. Na tomto článku je dobře vidět, kde jsou problémy sysv-init i upstartu při enterprise nasazení. Pro tuto situaci systemd nabízí přímočaré řešení, bez volání extra nástrojů jako start-stop-daemon nebo su, s efektivním využitím cgroups pokud služba vytváří libovolným způsobem další procesy, a s předvídatelným chováním napříč distribucemi.
-
Nejde o systemd jako takový, ale o to, že jedině systemd je v pozici vnutit linuxovému světu onu tolik potřebnou standardizaci a předvídatelnost. Je to taky názorný příklad toho, jak to, čemu někteří říkají "unixová filozofie" a já "unixová slátanina" je naprosto katastrofální z hlediska použitelnosti OS v reálném světě.
-
muf (neregistrovaný)
Od srdce jsem se zasmál nad tím, kam až může Poetteringovsky deformované myšlení zajít.
Z článku jednoznačně vyplývá, že upstart s takovou situací počítá a rozhodně nenutí uživatele startovat proces přes su. Byla to prostě volba uživatele.
Dokonce i ve starém sysV initu, který má, pravda, už po sezóně, to jde udělat lépe. Jako bonus tady máte téměř dokonalou průhlednost.No a věta o předvídatelnosti řešení nad systemd, to už je snad citát z nějaké kabaretní hry. To by ani Werich nevymyslel.
-
muf (neregistrovaný)
OK. Takže co takhle expect fork? su sice využijete, ale i na této staré verzi dojdete k žádoucímu výsledku bez špinavých triků díky upstartu.
I to článek zmiňuje.Autorovi článku vůbec nevyčítám, jaké řešení původně zvolil. Člověka to napadne téměř okamžitě a zdánlivě v tom nemůže být problém. Skoro jistě bych na ten problém narazil taky :-) Koneckonců kdysi jsem si naběhl podobně.
-
Jj, to souhlas. Ale na druhou stranu to je proste pak zase ono. Osobne o teto vlastnosti vim, ale v zivote by me to nenapadlo predtim, nez se mi stal podobny problem :-)
A proto mam radsi reseni ala systemd, kde se procesy managuji pomoci cgroups, uzivatele muzu nastavit rovnou a service manager vzdy vi, jake procesy bezi a ne (a nezalezi na tom, jak se co (ne)forkuje).
-
David Watzke (neregistrovaný)
Problém je, že přímo upstartí cookbook tohle volání "su" představuje: http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user
Píšou tam sice, že se na to "su" moc nehodí, že to není úplně košer, ale člověk se nedozví, že se tím takhle střelí do nohy.
-
Tak to je dost zasadni fail ale. Protoze dokumentace zminuje start-stop-daemon (neni v RHEL 6) a su/sudo, coz trpi timhle problemem. Oni pred su sice varuji, ale kvuli PAM restrictions (ktere zpusobuji zapis do wtmp).
Coz je vyrazne jiny druh problemu nez nasilne ukonceni procesu v pripade SIGTERM.
Ale to je proste cele o tom, ze upstart tyhle veci nemel (minimalne na zacatku) resene moc komplexne.I openrc tohle ma vyresene mnohem lepe.
-
mad (neregistrovaný)
Ja zas tvrdim, ze systemd je paskvil, ktery mi naopak uz zpusobil mnoho problemu, ktere bych bez nej resit vubec nemusel. Jeho nesmyslne a hrube zasahy do behu aplikaci odmitam a nesnasim. Jen z posledniho roku jsem kvuli systemd resil problemy s winbind, docker a dalsimi.
RedHat je v podstate maly fasisticky projekt, kteremu muzeme podekovat za zrudnosti typu avahi (ktery pro resolver zavadi vlastni .local DNS domenu), network manager nebo pulse audio. Uz muj prvni stret s nedokumentovanymi zasahy RedHat vyvojaru do zdrojaku (hwclock), ktere prisuzovali puvodnimu autorovi (kteremu jsem napsal, a on mi potvrdil, ze jeho zdrojak opravdu zmodifikoval nekdo jiny) mne presvedcili, ze v tomto projektu neco fatalne selhava ke skode opensource uzivatele.
Bohuzel, z pro mne nepochopitelnych duvodu se Debian take priklonil k systemd, pro mne osobne je to neodpustitelne. Kvuli lobby s virtualizaci, cloudy a typicky serverovym nasazenim se nejstarsi a nejsvobodnejsi
distribuce zamerena na stabilitu pustila do experimentovani s nedodelanym a system pohlcujicim smejdem, ktery ztezuje diagnostiku problemu, ktere by bez nej ani nevznikly. -
Sten (neregistrovaný)
Avahi používá .local, protože implementuje standard mDNS (RFC 6762), ne protože si to jeho autoři vymysleli. Za problémy s používáním neregistrovaných TLD si můžete sám.
Avahi ani PulseAudio nejsou projekty Red Hatu, ale freedesktop.org.
-
Problém systemd je v tom, že to není jen init, ale je k jeho zdrojákům příbalena i spousta programů, které tam nepatří, takže je z toho obrovský moloch – nadbytečná komplexita, která může být zdrojem chyb (jak bezpečnostních, tak funkčních).
Jinak souhlasím, že tuhle věc by měl řešit init, dokonce se mi i celkem líbí, jak to řeší systemd a i některé jeho další vlastnosti. Nakonec ho člověk v praxi použije, ale se skřípěním zubů… přitom je to škoda – mohlo by to být celkem dokonalé řešení, jen kdyby se rozdělil na jádro (init) a volitelné moduly.
P.S. ještě k tomu „enterprise nasazení“ – tohle není žádné „enterprise“, ale základní vlastnost, která by měla spolehlivě fungovat vždy a všude – i na nějakém konzumním tabletu nebo počítači pod televizí, který slouží jen k přehrávání filmů – i tam chceš spouštět a ukončovat služby pod různými uživateli a dát jim vhodný čas na to, aby se stihly korektně ukončit.
-
Filip JirsákStříbrný podporovatelProblém systemd je v tom, že to není jen init, ale je k jeho zdrojákům příbalena i spousta programů, které tam nepatří, takže je z toho obrovský moloch – nadbytečná komplexita, která může být zdrojem chyb (jak bezpečnostních, tak funkčních).
Od kdy je měřítkem komplexity to, co se společně nachází v repozitáři zdrojových kódů? Ostatně, když dáš dohromady zdrojáky SysVInitu, Bashe, GNU utils a ostatních nástrojů, které běžně rc skripty používají, bude těch zdrojáků nejspíš daleko víc.Navíc projekt systemd není a nemá být jenom init – je to skupina nástrojů vyvíjených pod jednou střechou, která mimo jiné obsahuje i init. Zdá se, že 80 % stížností na systemd by odpadlo, pokud by se binárka
systemdpřejmenovala nasystemd-init… -
Rozhodně nechci hájit starobylý SysV init. Modernější init systém je jednoznačně potřeba a systemd to dělá poměrně dobře – např. to, že služby jsou popsány spíš deklarativně než procedurálním skriptem, nebo že má větší kontrolu nad vzniklými podprocesy, že podporuje takové věci jako „socket activation“ atd.
Ale moje představa, jak by to mělo vypadat je, že bude jeden repozitář, ve kterém budou zdrojáky init systému a pak jiné repozitáře, kde budou zdrojáky volitelných modulů, různých NTP, DNS, HTTP a jiných serverů.
A když si pak budeš chtít zkompilovat init systém, tak do toho budou vstupovat jen zdrojáky init systému a ty ostatní si ani nemusíš stahovat. Opravdu v tom snížení komplexity a počtu řádků, které do toho vstupují, vidím přínos.
Také by to mělo být verzované sémanticky a po modulech, ideálně oddělit verzování API a implementace. Abych např. už z čísla verze init systému viděl, zda s ním bude kompatibilní moje služba – to, že mezitím někdo udělal nekompatibilní změny např. v NTP serveru mne nemusí nijak trápit a zvýšení jeho verze mi nevadí.
-
Filip JirsákStříbrný podporovatel
Oddělené repozitáře nebo sémantické verzování modulů jsou sice hezká věc, ale myslím, že jejich dopad na výsledné aplikace je neměřitelný – stejně jako může být v několika repozitářích houština neproniknutelných závislostí které jdou stejně přeložit jen všechny najednou, může být i v jednom repozitáři perfektně modulární systém.
Nepovažuju systemd za nějaký ideál. Ale když čtu, jak je systemd nepoužitelný moloch, a pak se dozvím, že je vlastně jen špatně pojmenovaná binárka a nehezky uspořádané zdrojáky, připadá mi to trochu neadekvátní…
-
Ad „stejně jako může být v několika repozitářích houština neproniknutelných závislostí které jdou stejně přeložit jen všechny najednou“
To právě ne – když nepůjde přeložit obsah jednoho repozitáře samostatně a nebude mít jasně deklarované závislosti, tak bude každému hned jasné, že to je špatně.
Ad „vlastně jen špatně pojmenovaná binárka a nehezky uspořádané zdrojáky“
Jenže to není nějaká kosmetická záležitost – je to zásadní návrhová/architektonická vlastnost. Rozdělit si systém/aplikaci na menší části a vyřešit si závislosti mezi nimi donutí člověka se víc zamyslet nad tím návrhem.
Ideální rozdělení bych si představoval takto:
- rozhraní mezi init systémem a službami (jen rozhraní, žádná implementace)
- implementace init systému, který umí spouštět služby, řeší jejich závislosti, ale neobsahuje tyto služby
- implementace jednotlivých modulů/služeb – sem patří např. moduly pro konfiguraci ethernetové sítě, podsvícení obrazovky, DNS, NTP, připojování disků atd.
Když bude rozhraní mezi init systémem a službami dobře navržené, tak ho můžou převzít i jiné init systémy (a používat např. to socket activation). Asi by to šlo napsat i tak, aby to bylo přenositelné na jiné posixové/unixové systémy (*BSD, Hurd, Solaris…).
Když si budu chtít např. postavit jednoduchou distribuci pro SoC desku, která nemá ani ethernet, ani displej s podsvícením ani milion dalších ptákovin, tak si z toho vezmu jen ten init systém a nebudu do toho zatahovat nějakých tři sta tisíc řádků kódu. Můj odhad je, že plnohodnotný init systém by měl jít – i v C – napsat na maximálně pár desítek tisíc řádků.
-
> rozhraní mezi init systémem a službami (jen rozhraní, žádná implementace)
https://www.freedesktop.org/wiki/Software/systemd/dbus/ + dalsi popisky tech rozhrani tam.
> implementace init systému, který umí spouštět služby, řeší jejich závislosti, ale neobsahuje tyto služby
https://github.com/systemd/systemd/tree/master/src/systemd
> implementace jednotlivých modulů/služeb – sem patří např. moduly pro konfiguraci ethernetové sítě, podsvícení obrazovky, DNS, NTP, připojování disků atd.
https://github.com/systemd/systemd/tree/master/src
>Když bude rozhraní mezi init systémem a službami dobře navržené, tak ho můžou převzít i jiné init systémy (a používat např. to socket activation). Asi by to šlo napsat i tak, aby to bylo přenositelné na jiné posixové/unixové systémy (*BSD, Hurd, Solaris…).
To neni mozne, protoze cely systemd je psany na miru Linuxu, stejne jako napr. launchd pro Darwin. A to plati i pro spravce sluzeb, protoze ten aby fungoval poradne, tak pouziva cgroups (linux only).
> Když si budu chtít např. postavit jednoduchou distribuci pro SoC desku, která nemá ani ethernet, ani displej s podsvícením ani milion dalších ptákovin, tak si z toho vezmu jen ten init systém a nebudu do toho zatahovat nějakých tři sta tisíc řádků kódu. Můj odhad je, že plnohodnotný init systém by měl jít – i v C – napsat na maximálně pár desítek tisíc řádků.
Vsak muzes. Krome systemd (spravce sluzeb), logind a udevd je vsechno ostatni je volitelny modul. Vzdyt se cely projekt systemd kompiluje do snad 60 binarek.
Takze vazne je takovy problem, ze to maji na githubu v jednom repozitari a ne v 70 (coz samozrejme dava smysl, protoze takhle se to mnohem jednodusi spravuje, vydava atd.) ?
-
Protoze to je adresar sdilenych hlavickych souboru, kdyz se na to podivas :)
Melo byt https://github.com/systemd/systemd/tree/master/src/core, nejak selhal clipboard.Ale porad trvam na tom, ze na modularite je uplne jedno, jestli je to v jednom nebo v X ruznych repozitarich.
-
BTW: nevíte někdo, proč bash completion pro systemd (např.
systemctl restart [tab]) odpovídá tak příšerně pomalu? Vždyť je to psané v céčku ne? Konfiguráky nejsou v XML a žádná Java tam taky není. :-)Když to srovnám se svým programem SQL-DK – a to jsem pro něj tehdy psal svůj vůbec první bash completion skript – tak ten napovídá okamžitě.
-
> Problém systemd je v tom, že to není jen init, ale je k jeho zdrojákům příbalena i spousta programů, které tam nepatří, takže je z toho obrovský moloch – nadbytečná komplexita, která může být zdrojem chyb (jak bezpečnostních, tak funkčních).
Tenhle argument slychavam casto a popravde, ani trochu nechapu proc. Skoro vse je v systemd volitelne.
Kdyz se mrknu na svuj pocitac, tak mi tu bezi:
systemd (init + zakladni funkcionalita systemu),journald (logovani),logind (sprava sezeni),udevd (udev)systemd projekt nikdy nebyl a nemel byt nahranou initu - jedna se o zakladni stavebni kameny userspace systemu, kam logicky veci jako sprava sluzeb, zarizeni, sezeni a zakladni logovani proste patri.
A naopak co se tyka bezpecnosti / chyb, tak toto "pod jednou strechou" vyvijene reseni mi prave proto prijde lepsi - pouziva ho skoro kazda distribuce (vs patlani si na vlastnim koleni u kazde trochu jinak zvlast).
-
- Tak prosím o systemd bez
- logind - ten mi rozbíjel konfiguraci ACPI tlačítek, a dělal různou další neplechu
A dále bych poprosil o udevd, kreré je testované i bez systemd. (Protože udev tu byl před systemd, nicméně přešlo pod vývojáře systemd.), to už mi na notebooku taky několikrát zavařilo. (Chyba byla třeba v laptop-mode-tools, protože nepředpokládal, že se udevd bez systemd chová jinak - jinak nastavuje procesgrupy procesům, které spouští.)
Takže teorie o modularitě je tu hezká, jen ta praxe poněkud pokulhává.
Btw., co se týče špatné dokumentace upstartu, která byla v tomhle vlákně zmíněná, tak systemd má máslo na hlavě daleko větší. Nejhorší je ale jeho protlačení distribucemi jako je Debian, bez toho aby byly k dispozici kvalitní/odladěné unit fily. Tady byl vývoj posunut o 10 let zpět, kdy je potřeba znovu ladit start daemou. Například sshd, naprosto klíčový daemon pro správu serveru v debian Jessie. Někdo napsal unit file po rychlém přečtení dokumentace, a nedozvěděl se z toho, že 'systemctl restart sshd zkončí úspěchem, i když následně ssh spadne na chybu v konfiguraci. Zrovna v debianu Jessie je podle mého názoru vadných asi 90% unit filů.
-
> Tak prosím o systemd bez logind - ten mi rozbíjel konfiguraci ACPI tlačítek, a dělal různou další neplechu
> A dále bych poprosil o udevd, kreré je testované i bez systemd. (Protože udev tu byl před systemd, nicméně přešlo pod vývojáře systemd.), to už mi na notebooku taky několikrát zavařilo. (Chyba byla třeba v laptop-mode-tools, protože nepředpokládal, že se udevd bez systemd chová jinak - jinak nastavuje procesgrupy procesům, které spouští.)logind i udevd celkem neodmyslitelne patri k zakladnim komponentam userspacu (coz je presne to, co resi systemd - nikoliv nahradu initu, to je jen jedna z funkci). Takze tezko to chtit po autorech systemd, aby psali neco takoveho, kdyz o to sami (RH) nemaji zajem a nezapada to ani do koncepce projektu.
Ale z komunitnich projektu tu existuje eudev a systemd-shim. Ale neni moc duvod tohle chtit po vyvojarich systemd / RH.
Modularitou bylo mysleno, ze velka cast sstemd komponent je volitelna pri kompilaci / instalaci, nikoliv ze je mozne vzit jakoukoliv jeho komponentu a pouzivat ji bez jejich zavislosti :)
> Nejhorší je ale jeho protlačení distribucemi jako je Debian, bez toho aby byly k dispozici kvalitní/odladěné unit fily.
To souhlas, s Debianem sice moc nedelam, ale obecne vetsinu problemu, ktere jsem se systemd zazil, byly horkou jehlou udelane (spatne) unit files. -
j (neregistrovaný)
Takze zase zvasnis o modularite ktera naprosto neexistuje, ostatne jako vsichni fanboyove tyhle sracky.
A protoze ses znamej sklerotickej blb, tak citace "vse je v systemd volitelne" ... hovno hovno co?
Ale vis co, jmenuj JEDNU JEDINOU cast systemd, kterou lze provozovat BEZ systemd. Systemd ZADNOU modularitu nema, a nikdy nemel. Je to jeden gigantickej nefunlkcni blob.
-
Pokazit se může cokoli i bez systemd. Můžeme se sice bavit o tom, kde je ta pravděpodobnost vyšší, ale nulová není nikdy. Tudíž ze vzdáleného produkčního systému, ke kterému nemám jiný přístup (sériový port i do BIOSu a GRUBu nebo KVM…) než SSH nebo něco podobného běžícího uvnitř toho systému, bych měl nepříjemný pocit a to bez ohledu na to, jestli tam systemd je nebo není.
-
j (neregistrovaný)
Jasne, podelat se muze cokoli, za 30let se mi nestalo ze by chcipnul logger, mozna nekomu obcas nejakej chcipnul, pouzivam ruzny. Systemd neloguje se zcela 100% jistotou vzdycky, kdyz je treba resit proc neco nefunguje, protoze odpoved je jednoducha ... protoze systemd se opet posral.
