Vlákno názorů k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL? od Heron - Díky za článek, je poučné se zamyslet nad...

> Proč by měl být su ojeb? (Bavíme se o funkční a zdokumentované variantě, nikoliv o tom problémovém v článku.) Mě to naopak přijde jako součást unixové myšlenky, jeden program dělá jednu věc a to (v tomto případě) omezení práv spouštěného programu. Stejně jako tam může být nice, ionice apod.
Protoze treba tento problem. Protoze to vytvari ve stormu procesu zbytecnou entry? Protoze tam su musi existovat? Protoze to vytvari binec s posilanim signalu (neni to jen tento pripad v clanku - ale obecne to preposilani signalu je prasarna). Protoze pak spravce sluzeb nevidi skutecny master proces?
Protoze je to tak elementari zalezitost (spustit program pod jinym uzivatelem nez je root), ze by to mel byt naprosto dany standard u kazde sluzby?

> Na tom nevidím nic špatného, protože je to naprostý prd ve srovnání s tím, co většina programů řeší jako svoji hlavní práci.
To neni argument, proc to ma resit - stejne tak muzu rict, ze implementace vlastniho linked listu je trivialita proti tomu, co musi vetsina programu resit a stejne ho nikdo sam implementovat nebude :-)

> Existují knihovny. I na toto. Takže není nutné duplikovat nic. Dokonce existují programy, které vše zařídí.
Ano existuji, ale pointa je, ze pak si to kazdy program resi jinak. Pokud je to odpovednosti spravce sluzeb, je to na jednom miste, v jednom formatu konfigurace.
A nevznika mi tam nejaky potencialne bugnuty meziclanek, ktery se (zcela zbytecne) spusti pod rootem.

> Ale on se o to stará správce služeb. I u toho sysvinitu. Prostě tím formátem, ve kterém je to napsané, je bash (krom jiného je to i skriptovací jazyk a interaktivní prostředí pro spouštění programů). Ještě před x lety na tom nikomu nepřišlo nic divné.

Nestara, spoleha na externi programy, ktere mohou a nemusi byt k dispozici, nema jednotne rozhrani pro specifikaci zcela zakladnich veci (uzivatel, capabilities, ...) - viz start-stop-daemon v tomto clanku. Navic ani nevi, jake procesy vlastne sluzba ma spustene - staci udelat nekolik forku a upstart / sysvinit vubec nevi, co kde bezi.
Takze ano, mozna to neprislo pred lety nikomu divne (i kdyz prislo, vsem kdo videly jine service managery na jinych OS a neznaly aspon daemon tools), ale robustni to neni ani omylem.

Mě to naopak přijde jako součást unixové myšlenky, jeden program dělá jednu věc a to (v tomto případě) omezení práv spouštěného programu. × Na tom nevidím nic špatného, protože je to naprostý prd ve srovnání s tím, co většina programů řeší jako svoji hlavní práci.
Neprotiřečíte si trošku?

Problémy jsou pouze s problémovými programy.
No jo, ale co s těmi problémovými programy máme dělat? Zahodíme Apache, zahodíme nginx, zahodíme Postfix, zahodíme PostgreSQL – a zbydou nám vůbec nějaké nějaké neproblémové programy?

Jsem té zásady, že problém by měl vybublat na povrch co nejdříve a nikoliv se skrývat pod dalšími vrstvami. × Existují knihovny. I na toto.
Neprotiřečíte si?

To lze udělat v libovolném správci služeb.
V SysVInitu to udělat nejde. Jde to udělat vedle něj.

Prostě tím formátem, ve kterém je to napsané, je bash
Tak se pak ale nedivte těm zpraseným init skriptům. To je přesně to, co chcete – každý si to sám napíše v bashi jak nejlépe dovede.

Ještě před x lety na tom nikomu nepřišlo nic divné.
To je průvodní jev pokroku, že nám přijdou divné věci, které před nějakou dobou divné nebyly.

Neprotiřečíte si trošku?

Ne, nechávám to na autorovi toho programu. Obě možnosti jsou pro mě přijatelné. Reagoval jsem jen na komentář, který su považuje za ojeb.

Neprotiřečíte si?

Ne, knihovna je soubor kódu a opět je to reakce na komentář k možné duplikaci. Knihovna není vrstva, která něco skrývá.

V SysVInitu to udělat nejde. Jde to udělat vedle něj.

To je jen slovíčkaření. rc.v skripty lze považovat za součást sysv a v těchto skriptech se nastaví prostředí pro běh programu.

Tak se pak ale nedivte těm zpraseným init skriptům. To je přesně to, co chcete – každý si to sám napíše v bashi jak nejlépe dovede.

No já se jim nedivím, já na ně jen upozorňuji. Pro mě je toto další indicie k rozhodování, že tomuto programu je lepší se vyhnout. Pokud neumí slušně napsat ani startovací skript, jak to asi vypadá uvnitř.

> Ale on se o to stará správce služeb. I u toho sysvinitu. Prostě tím formátem, ve kterém je to napsané, je bash (krom jiného je to i skriptovací jazyk a interaktivní prostředí pro spouštění programů). Ještě před x lety na tom nikomu nepřišlo nic divné.

Tak spravce systemu je snad svepravny clovek, aby se rozhodl, jestli automaticky restart chce nebo ne. Jsou situace, kde je to zcela v poradku a namiste a situace, kde je to extremne nevhodne. Ale to si musi rozhodnout kazdy spravce.
Ale nedat tu moznost je rozhodne spatne. Proc bych napr. na testovacim serveru nemel mit nastaveny automaticky restart, kdyz tam spoustim X sluzeb a obcas jim proste dojde pamet?

> Tak to nemají psát a mají to nechat nějakému správci systému, který to napíše. Jako tohle je výmluva jak noha, tj jak kdyby jsi byl v nemocnici na operaci a místo anesteziologa tě hlídala instrumentářka, protože byla zrovna po ruce...

A proc ma firma / dodavatel / ... platit spravce, aby psal porad to stejne dokola dokolecka, navic s moznosti vzniku chyby? Proc to nevyresit spravcem sluzeb, stejne jako ve vetsine jinych OS (Windows, MacOS, Linux se systemd - vsimni si, ze to pokryva vyraznou majoritnu dnes pouzivanych OS - ze by na tomto pristupu neco bylo podle tvurcu ?:) )?

Tak spravce systemu je snad svepravny clovek, aby se rozhodl, jestli automaticky restart chce nebo ne.

Byla řeč o unitách v systemd. Ty nenastavuje správce (může), ale za jednu z hlavních výhod systemd tady bylo před lety ohlašováno to, že unitu napíše autor programu a napíše ji jednou a poběží to všude. A právě v těchto unitách od některých autorů se objevuje nebezpečně často restart on failure.

Proc bych napr. na testovacim serveru nemel mit nastaveny automaticky restart, kdyz tam spoustim X sluzeb a obcas jim proste dojde pamet?

Tak třeba by tě to donutilo to zoptimalizovat. ;-) Pro mě za mě si na testovacím prostředí dělejte třeba stojky, ale do produkce by to patřit nemělo. A systemd rozhodně není jediná možnost automatického restartu. Jen je nejvíc viditelná a propagovaná.

A proc ma firma / dodavatel / ... platit spravce

Protože chce, aby ten program byl po všech stránkách perfektní? A jistě je dobré si do týmu přibrat taky někoho, kdo se potom o běh toho programu bude starat a může poradit, které věci v praxi nejvíc překážejí apod. Tyhle argumenty dost dobře nechápu, někdy mám pocit, že (podle těchto komentářů) vývojáři chtějí prostě jen psát to své dokonalé dílo, ale to, že to potom nejde spustit a jsou s tím starosti už je jaksi nezajímá.

> Byla řeč o unitách v systemd. Ty nenastavuje správce (může), ale za jednu z hlavních výhod systemd tady bylo před lety ohlašováno to, že unitu napíše autor programu a napíše ji jednou a poběží to všude. A právě v těchto unitách od některých autorů se objevuje nebezpečně často restart on failure.
Tak autor .service (vendor distribuce / programu) je snad jeste vice svepravny nez i bezny admin, aby rozhodl, jaky ma byt default (ktery muze admin snadno zmenit).

> Tak třeba by tě to donutilo to zoptimalizovat. ;-) Pro mě za mě si na testovacím prostředí dělejte třeba stojky, ale do produkce by to patřit nemělo. A systemd rozhodně není jediná možnost automatického restartu. Jen je nejvíc viditelná a propagovaná.
A proc bych to mel optimalizovat, kdyz proste je to treba jen prostredi, kde overcommituji pamet? Nebo je to sluzba, kde restart nevadi (at uz probehne z jakehokoliv duvodu)? Usecases je mraky, kde to ma smysl.
A hlavne, nikdo nikoho nenuti to pouzivat :)
A ze by byl systemd jedina varianta nikdo nikdy netvrdil, je jedna z mnoha ruznych reseni.

> Protože chce, aby ten program byl po všech stránkách perfektní? A jistě je dobré si do týmu přibrat taky někoho, kdo se potom o běh toho programu bude starat a může poradit, které věci v praxi nejvíc překážejí apod. Tyhle argumenty dost dobře nechápu, někdy mám pocit, že (podle těchto komentářů) vývojáři chtějí prostě jen psát to své dokonalé dílo, ale to, že to potom nejde spustit a jsou s tím starosti už je jaksi nezajímá.

Ukaz mi firmu, ktera chce platit, aby bylo neco perfektni :-) Naopak soucasnym trendem je treba Microservices architektura - uz z jeji podstaty plyne, ze potrebuji, aby spusteni sluzby bylo maximalne jednoduche, automatizovane a vyzadovalo minimum manualni prace.

> Tyhle argumenty dost dobře nechápu, někdy mám pocit, že (podle těchto komentářů) vývojáři chtějí prostě jen psát to své dokonalé dílo, ale to, že to potom nejde spustit a jsou s tím starosti už je jaksi nezajímá.

No a pokud se pouzije rozumny spravce sluzeb, tak se prave o to vyvojar vubec nemusi starat,

Byla řeč o unitách v systemd. Ty nenastavuje správce (může)
Další výhodou unit je také to, že je snadné je skládat. Takže autor si do unity napíše automatický restart, a já si pak ve své konfiguraci ten automatický restart zase vypnu. A nemusím řešit, že bych s příští verzí aplikace musel patchovat nějaký skript.

Jenže v praxi vidíme to, před čím jsem tady v diskusích varoval už před x lety a to zneužívání automatického restartu. Nevím jak ty, ale já to v těch unitách a ještě ke všemu v mnoha různých článcích pro začátečníky, vidím čím dál častěji.
Já zase v SysVInit skriptech vidím zneužívání bashe, nesrovnatelně horší a nesrovnatelně zákeřnější, než nějaké automatické restarty služeb. Mnohokrát si tu napsal, že se něco dá řešit i v SysVInitu – stejně tak si tam někdo může naskriptovat i ty automatické restarty.

Tak to nemají psát a mají to nechat nějakému správci systému, který to napíše. Jako tohle je výmluva jak noha
To není výmluva, to je popis reality. Kafka se používá docela hodně, a zjevně se za celou dobu nenašel jediný správce, který by se nad těmi skripty zhrozil, přepsal by je a poslal do upstreamu.

Ano, což potom dopadá přesně tak, že je skoro nemožné ji jako službu spustit a to i v tom "moderním správci služeb".
Nikdy jsem neměl problém s tím spustit nějaký skript nebo běžnou konzolovou aplikaci pod daemontools nebo systemd.

stejně tak si tam někdo může naskriptovat i ty automatické restarty

Tak jistě, ale je to větší potenciální bariéra (tj větší množství lidí se tomu raději vyhne), než jeden řádek v unitě o kterém se dozví hned z prvního tutoriálu.

a zjevně se za celou dobu nenašel jediný správce

Ten správce, který to napíše, by měl být ideálně součástí týmu, který to vyvíjí.

Nikdy jsem neměl problém s tím spustit nějaký skript nebo běžnou konzolovou aplikaci pod daemontools nebo systemd.

Já jo. Ve chvíli, kdy mám obě ruce na tvářích a očích, abych tu hrůzu v té unitě neviděl, už mě nezbývají další končetiny k dokončení práce. Tímto hw lockem se příroda brání podobným zvěrstvům. To, že to jde spustit a systemd si s tím nějak poradí, nezpochybňuju. Ale otázkou je, zda je to tak správně.

Tak jistě, ale je to větší potenciální bariéra (tj větší množství lidí se tomu raději vyhne), než jeden řádek v unitě o kterém se dozví hned z prvního tutoriálu.
To je zvláštní, že u SysVInitu jsou bash skripty výhodou, zatímco v případě automatického restartu jsou bariérou.

Ten správce, který to napíše, by měl být ideálně součástí týmu, který to vyvíjí.
Jako že za půl dne napíše startovací skripty pro různé systémy, a pak se bude několik měsíců nebo let nudit?

To, že to jde spustit a systemd si s tím nějak poradí, nezpochybňuju. Ale otázkou je, zda je to tak správně.
Nenapsal jste nic konkrétního, s čím byste měl problém u běžné konzolové aplikace, která počítá s tím, že ji někdo spustí z příkazového řádku na popředí.

To je zvláštní, že u SysVInitu jsou bash skripty výhodou, zatímco v případě automatického restartu jsou bariérou.

Co je na tom zvláštního? Naučit se skriptovat v bashi je přece složitější, než dopsat jeden řádek do unity (nebo override). Pokud se někdo ten bash naučí lépe, tak je pro něj výhodou. A ve chvíli, kdy bude schopen spolehlivě napsat restart v rc skriptu, tak už jej možná nebude potřebovat, protože ta jeho appka už nebude padat, protože ji mezitím doladil. (Bavím se v kontextu toho, že autor appky je stejný, jako autor toho rc skriptu.)

Jako že za půl dne napíše startovací skripty pro různé systémy, a pak se bude několik měsíců nebo let nudit?

Ne, těch dalších několik měsíců může kafrat do vývoje a radit vývojářům a pomoci tak vyvinout lepší produkt, který lépe poběží na cílové platformě (což je věc, která, soudě dle některých komentářů, vlastně nikoho nezajímá - většinou krom těch správců).

která počítá s tím, že ji někdo spustí z příkazového řádku na popředí

Ano, a teď si dáme pět minut předstírání, že všechny appky jsou napsané přesně takto.

Kdyby tomu tak bylo, tak bohatě stačí sysvinit s trochou snahy i bez rc skriptů a vše je v pořádku a jednoduché. Takže pokus o změnu kontextu je to sice pěkný, ale sám víš, že se tady bavíme o programech, které z různých důvodů nespolupracují. Kdyby bylo vše takto ideální, tak nepotřebujeme ani systemd.

> Co je na tom zvláštního? Naučit se skriptovat v bashi je přece složitější, než dopsat jeden řádek do unity (nebo override). Pokud se někdo ten bash naučí lépe, tak je pro něj výhodou. A ve chvíli, kdy bude schopen spolehlivě napsat restart v rc skriptu, tak už jej možná nebude potřebovat, protože ta jeho appka už nebude padat, protože ji mezitím doladil. (Bavím se v kontextu toho, že autor appky je stejný, jako autor toho rc skriptu.)

To nemeni nic na tom, ze je to zbytecna, repetetivni prace. A jediny, kdo tuhle moznost (moznost, ne povinnost) nenabizi out of the box je sysv init. Proc to vsechny ostatni platformy asi umoznuji ?:-)

> Ne, těch dalších několik měsíců může kafrat do vývoje a radit vývojářům a pomoci tak vyvinout lepší produkt, který lépe poběží na cílové platformě (což je věc, která, soudě dle některých komentářů, vlastně nikoho nezajímá - většinou krom těch správců).

Tak takovy zamestnanec se rozhodne vyplati :-))

> Ano, a teď si dáme pět minut předstírání, že všechny appky jsou napsané přesně takto.

Nemusime, protoze skoro vsechny napr. v korporatech vyvijene microservices jsou napsane presne takto. Tento zpusob navic funguje perfektne v Dockeru.
Jediny duvod, proc to maji nektere UNIX daemony jinak je - ze to se sysvinitem jinak neslo :)

> Kdyby tomu tak bylo, tak bohatě stačí sysvinit s trochou snahy i bez rc skriptů a vše je v pořádku a jednoduché. Takže pokus o změnu kontextu je to sice pěkný, ale sám víš, že se tady bavíme o programech, které z různých důvodů nespolupracují. Kdyby bylo vše takto ideální, tak nepotřebujeme ani systemd.

Opravdu? Bavime se o spousteni normalnich sluzeb. Jak prenositelne udelam v sysv initu to, ze sputim program jako daemon, uvidim jeho logy posilane na stdout, bude mi trackovat jeho veskere subprocesy bez ohledu na zpusob forkovani, zajistim ze neuvidi sdileny /tmp a /var bude mit readonly bez ohledu na FS prava, omezim mu capabilities, omezim mu pristup k zarizenim atd. bez toho, abych musel instalovat dalsi pomocne utility v systemu ?:-)
systemd tohle vsechno umi out of the box diky cgroups / fs namespaces a dalsim, je to prehledne v jednom konfiguracnim souboru (.service) a muzu to snadno auditovat i prenaset mezi systemy...

Naučit se skriptovat v bashi je přece složitější, než dopsat jeden řádek do unity (nebo override).
Takže se snad můžeme shodnout na tom, že je nevýhodou SysVInitu, že pro spuštění jakékoli služby vyžaduje znalost složitějšího bashe (nebo nějaký jiný externí nástroj).

Ne, těch dalších několik měsíců může kafrat do vývoje a radit vývojářům a pomoci tak vyvinout lepší produkt, který lépe poběží na cílové platformě (což je věc, která, soudě dle některých komentářů, vlastně nikoho nezajímá - většinou krom těch správců).
To ovšem máte dost idealizovanou představu o správcích. Protože většina správců nemá takové znalosti o systému, aby mohli něco kloudného radit vývojářům. Podobně jako většina vývojářů nemá znalosti na to, aby napsali rozumný startovací skript. Aplikace, systém a provoz jsou tři různé věci, a je málo lidí, kteří jsou vynikající v jednom, obstojně znají druhé a zvládnou i třetí.Většinou jsme rádi, když ten člověk obstojně zvládá jednu z těch oblastí.

Ano, a teď si dáme pět minut předstírání, že všechny appky jsou napsané přesně takto.
To nikdo netvrdil. Ty jsi naopak napsal, že u běžné aplikace, která se nestará o to, aby běžela jako služba, je skoro nemožné takovou aplikaci spustit jako službu i pod moderním správcem služeb.

bavíme se o programech, které z různých důvodů nespolupracují
Moje zkušenost je taková, že zpravidla nespolupracují programy, které byly psané s ohledem na SysVInit, takže se snaží samy starat o to, aby běžely jako služba, a typicky první, co dělají, že se snaží dostat z dosahu rodiče. Různé programy nebo skripty v Pythonu, Javě, Perlu nebo jednoduché programy v C/C++, které někdo psal s vidinou toho, že ten program prostě někdo spustí z příkazového řádku a ten program poběží, dokud ho někdo pomocí Ctrl+C neukončí, nemají s daemontools nebo systemd vůbec žádný problém – prostě se napíše ten samý příkaz, jaký se používá pro spuštění toho programu z příkazové řádky, případně se doplní změna uživatele nebo nějaká omezení, a ono to funguje.

Takže se snad můžeme shodnout na tom, že je nevýhodou SysVInitu, že pro spuštění jakékoli služby vyžaduje znalost složitějšího bashe (nebo nějaký jiný externí nástroj).

Já další znalost něčeho nepovažuji za nevýhodu. Navíc je podle mě vhodná jistá potenciálová bariéra k tomu, aby ten člověk potom mohl dělat něco dalšího. Asi je k diskusi, zda by to měl být zrovna bash, ale myšlenka je snad jasná.

Podobně jako většina vývojářů nemá znalosti na to, aby napsali rozumný startovací skript. Aplikace, systém a provoz jsou tři různé věci, a je málo lidí, kteří jsou vynikající v jednom, obstojně znají druhé a zvládnou i třetí.

Ale já jsem netvrdil, že jeden člověk musí zvládnout všechno. Já jsem tvrdil, že by si do toho vzájemně měli kecat, protože to, co je obtížné udělat na jedné úrovni (třeba ve vývoji appky), tak je hračkou udělat jinde (třeba pro admina). A naopak. Jako asi nechci zacházet do detailů, protože nechci nikoho konkrétního poškodit, ale zažil jsem opakovaně situace, kdy někdo vyvíjel cosi, poměrně složitě a zdlouhavě a přitom vůbec netušil, že už to cosi je součástí OS a admini to používají takřka denně a důvěrně znají. Ano, to že vývojáři nemají přehled o OS já moc dobře vím a považuji to za chybu a proto píšu, že by admini měli víc kecat do práce vývoje (a naopak) a sdílet tak věci, které možná druhá strana do té doby nevěděla a toto celkově povede ke kvalitnější appce, kterou bude radost provozovat.

Různé programy nebo skripty v Pythonu, Javě, Perlu nebo jednoduché programy v C/C++, které někdo psal s vidinou toho, že ten program prostě někdo spustí z příkazového řádku

Ale však jistě, na tom se shodneme a s těmito programy není žádný problém a nebyl ani před systemd. Odpoutání od rodiče lze udělat pomocí nohup, přesměrování výstupu do logu nebo do jiné (třeba logovací) appky taky, změna uživatele pomocí su, změna prio pomocí nice apod. Prostě s těmito programy není žádný problém.

> Ale však jistě, na tom se shodneme a s těmito programy není žádný problém a nebyl ani před systemd. Odpoutání od rodiče lze udělat pomocí nohup, přesměrování výstupu do logu nebo do jiné (třeba logovací) appky taky, změna uživatele pomocí su, změna prio pomocí nice apod. Prostě s těmito programy není žádný problém.

Ano, neni zadny problem, jen o takovem pouziti su tu vznikne clanek po kdovijak dlouhe umorne investigaci toho, proc se presne takovy druh sluzby nekorektne ukoncuje :-D

Ano, neni zadny problem, jen o takovem pouziti su tu vznikne clanek po kdovijak dlouhe umorne investigaci toho, proc se presne takovy druh sluzby nekorektne ukoncuje :-D

Jestli jste si nevšiml, tak už v článku samotném je uvedeno, že implementací su je víc a dokonce někdo v diskusi napsal, že to, jak se su chová v distribuci použité v článku neodpovídá dokumentaci. Jinými slovy, ten konkrétní program je vadný (nebo je vadná dokumentace). Stejně tak může být vadná i příslušná část toho moderního správce služeb.

Jinými slovy, ten konkrétní program je vadný (nebo je vadná dokumentace). Stejně tak může být vadná i příslušná část toho moderního správce služeb.
V případě toho su je to ovšem okrajový případ, se kterým se moc nepočítá. Navíc když se liší program su na jednotlivých distribucích, mže se úplně stejně lišit i ta dokumentace… Naproti tomu u moderního správce služeb je to klíčová funkcionalita, takže je mnohem méně pravděpodobné, že by tam byla takováhle vada.

Já další znalost něčeho nepovažuji za nevýhodu.
Já také ne. Ale něco jiného je znalost uživatele, který ji použije, když se mu to hodí – a něco jiného je vyžadování té znalosti ze strany nástroje. Když někdo umí pilotovat letadlo, je to určitě fajn, ale mám raději auta, která lze řídit i bez pilotního průkazu.

Ano, to že vývojáři nemají přehled o OS já moc dobře vím a považuji to za chybu a proto píšu, že by admini měli víc kecat do práce vývoje (a naopak) a sdílet tak věci, které možná druhá strana do té doby nevěděla a toto celkově povede ke kvalitnější appce, kterou bude radost provozovat.
S tím já souhlasím, ale nemyslím si, že by cestou k tomu byly šílené bash skripty suplující práci správce služeb. Myslím, že se vývojáři o OS dozvědí mnohem víc, pokud mohou aplikaci jednoduše vzít, napsat pár řádků unit file a aplikace se jim spustí. Ostatně k tomu, aby vývojáři věděli víc o systému, směřuje třeba princip DevOps, který se zase rozšiřuje s kontejnerovými technologiemi a speciálně s Dockerem. Jak systemd tak Docker využívají podobných moderních vlastností linuxového jádra, a myslím, že k zvětšení znalostí vývojářů o Linuxu přispěly mnohem víc, než cokoli před nimi. Ano, obě implementace jsou kontroverzní, ale směr, kterým ukazují, je podle mne jednoznačně správný.

Prostě s těmito programy není žádný problém.
Jsem rád, že jsme se od „ je skoro nemožné ji jako službu spustit a to i v tom 'moderním správci služeb'“ dostali k „prostě s těmito programy není žádný problém“.

S tím já souhlasím, ale nemyslím si, že by cestou k tomu byly šílené bash skripty suplující práci správce služeb.

Tak suplující. Je otázkou, zda by nějaký správce služeb měl vůbec existovat a pokud ano (což není triviální otázka) tak jakou by měl mít podobu. Prostě tady se diskuse začíná od konce, argumentuje se tím, co který správce služeb umí nebo neumí, mnozí lidé mají představu toho svého dokonalého správce služeb a ani nejsou schopni jej definovat (narážím na Poetteringa). Tady se staví správce služeb který už je daleko větší, než jen init + rc a nikde za ty roky není definováno, co by to vlastně mělo být a kam to směřuje. To lze pouze hádat z té rozdělané práce. V průběhu toho se přidávají vlastnosti, které se někomu líbí a někomu méně, ale co to vlastně je je pořád nejasné.

šílené bash skripty

Hele, mě se bash taky nelíbí. Co se mi ale na původních sysv + rc skriptech konceptuálně líbí je to, že je to vybudované z toho, co již v systému tak jako tak existuje. Takže máme nějaký jazyk pro interaktivní spouštění programů, lze v něm psát skripty, tak z toho uděláme rc systém. Vypomůžeme si základními gnu příkazy a je to. Pro admina tam není nic, co by nemohl znát z běžné práce na řádce. Tohle je pro mě obrovská síla toho, co unixová filozofie dokáže. Máme nějaké atomy a z těch to postavíme.

A když to vezmu z hlediska uživatele, tak co může být lepší reklamou pro příkazy, které mu jsou nabízeny v shellu, než to, že je z nich postaven i ten systém? Tímto stylem se podle mě o systému naučí mnohem víc, než v dockeru, viz. následující bod.

Jak systemd tak Docker využívají podobných moderních vlastností linuxového jádra, a myslím, že k zvětšení znalostí vývojářů o Linuxu přispěly mnohem víc, než cokoli před nimi.

Uff. Nemám pocit, že by se někdo nasazením dockeru naučil víc o linuxu. Právě naopak. Docker a podobné technologie nalákaly lidi, kteří o linuxu neví vůbec nic, nechtějí o něm nic vědět a kvůli dockeru se k němu ani nedostanou, protože vše, co to má dělat, si napíšou v nějakém tom dockerfile. Image stahují z různých míst, zbastlí to, aby to už běželo a ještě ke všemu je to všechno pod rootem, protože práva jsou otrava.

Jsem rád, že jsme se od „ je skoro nemožné ji jako službu spustit a to i v tom 'moderním správci služeb'“ dostali k „prostě s těmito programy není žádný problém“.

Stylem jeden o voze, druhý o koze.

Tady se staví správce služeb který už je daleko větší, než jen init + rc a nikde za ty roky není definováno, co by to vlastně mělo být a kam to směřuje.
Jako by snad u SysVInitu + rc skriptů bylo definováno, co by to mělo být a kam to směřuje. Mít předem úplnou specifikaci by bylo hezké, ale ve světě opensource se mnohem častěji vyvíjí stylem „kecy jsou levné, ukaž mi kód“. Se SysVInitem bylo nespokojených dost lidí, některé chyby byly pojmenované, a občas prostě někdo zkusil napsat něco lepšího. Chronologicky nejmladší je asi systemd, nikdo si nemyslí, že by bylo poslední.

Co se mi ale na původních sysv + rc skriptech konceptuálně líbí je to, že je to vybudované z toho, co již v systému tak jako tak existuje.
To mě se líbí také, ale jedině tehdy, pokud je to bonus navíc k základní funkci. Jenže v případě init skriptů musela tomuto bonusu ustoupit základní funkcionalita, a to je pro mne nepřijatelné. Systemd nepřišel s ničím principiálně novým, to co dělá, by se taky dalo poslepovat v shellu – ale nikdo to neudělal. Nikdo neprosadil to, že se spouštění služby nebude skriptovat v shellu, ale popíše se, jak má ta spuštěná služba vypadat, a nějaký bazmek (klidně napsaný v shellu) se postará o to, aby se ta služba v takovém stavu spustila. Už jenom ten deklarativní zápis, i když je u systemd dost divný, je obrovský přínos – protože teď může přijít kdokoli jiný, a na základě toho popisu spustit službu svým nástrojem. Klidně někdo může napsat shell skript, který bude interpretovat systemd unit soubory a spouštět ty služby pod SysVInitem. Tohohle nejde s „popisem“ služby v shellovém skriptu nikdy dosáhnout, protože tam není popsáno, co je cílem, ale jak toho dosáhnout – a nikdo nedokáže napsat nástroj, který by z toho to „co“ vždy spolehlivě zjistil.

A když to vezmu z hlediska uživatele, tak co může být lepší reklamou pro příkazy, které mu jsou nabízeny v shellu, než to, že je z nich postaven i ten systém? Tímto stylem se podle mě o systému naučí mnohem víc, než v dockeru, viz. následující bod.
Jenže spousta lidí nechce používat shell nebo se ho dokonce naučit, oni chtějí jen spustit web server jako službu.

Docker a podobné technologie nalákaly lidi, kteří o linuxu neví vůbec nic, nechtějí o něm nic vědět
Ano, nalákali lidi, kteří dříve o linuxu nevěděli vůbec nic a ani ho žádným způsobem nepoužívali – vstupní bariéra pro ně byla příliš velká. Teď se ale k linuxu dostanou mnohem snáz, začnou ho používat – a někteří se budou chtít dozvědět víc.

Stylem jeden o voze, druhý o koze.
Já jsem začal o programech, u kterých se jejich autor nestará o to, aby ten program běžel jako služba. Pokud ty jsi pokračoval o něčem jiném, není to moje chyba. Pokud jsi pokračoval o tom stejném, neuvedl jsi jediný příklad, že by se autor programu nestaral o to, že poběží jako služba, a kvůli tomu by byl problém se jeho spuštěním pod moderním správcem služeb.

Mít předem úplnou specifikaci

Nejde o specifikaci. Jde o filozofii. Co by mělo být výsledkem. Stačí půl stránky.

Jenže v případě init skriptů musela tomuto bonusu ustoupit základní funkcionalita, a to je pro mne nepřijatelné.

No vidíš a pro mě je důležitější čistota systému, než tam mít něco pro funkcionalitu, kterou lze řešit jinak.

a někteří se budou chtít dozvědět víc

To je jistě možné, ale otázkou je, proč tak neudělali doposud, když vstupní bariéra posledních 20 let vypadá přibližně tak, že při instalaci stačí několikrát odentrovat a je hotovo. Nehledě na to, že hezkých pár let existují předinstalovaná vmka, kde si to mohl každý kdo chtěl vyzkoušet. Druhá strana mince je ta, že lidi, kteří by byli schopni do toho více proniknout zůstanou jen u dockeru a nikam dál se neposunou. Nevím, kde je ta hranice, kdy je to ještě přínosné a kdy škodlivé.

Já jsem začal o programech, u kterých se jejich autor nestará o to, aby ten program běžel jako služba.

Ano ale potom jsi tiše automaticky předpokládal, že se ten program bude chovat slušně. Ale to není automaticky splněno. Příkladem budiž minecraft server, který (jak již název napovídá) je herní server. A přesto je docela obtížné jej jako server provozovat.

Ano, když si jej někdo spustí čistě v terminálu, tak jede. Jenže jeho spuštění skončí na něčem jako readline, tj že očekává příkazy, má vlastní prompt apod.. Naštěstí reaguje i na stdin. Roky se to řešilo tak, že se uzavřel do vlastní screen / tmux session a pomocí send keys funkcionality, se tomu posílaly příkazy. Jenže výstup (stdout) nikde nebyl vidět (resp. byl vidět jen v té screen / tmux session, nikam se to nelogovalo).

Prostě to, že "se autor nestará o to, aby ten program běžel jako služba" může dopadnout tak, že to jako služba půjde spustit poměrně obtížně. Kdyby ten mc server měl ovládání nezávislé od té služby, tak by to bylo o něčem jiném.

Jako ono to nakonec rozjet jde a v systemd dokonce s výhodou předávání socketů na stdin (ale zase je tam aktivní socket activation). Ale rozhodně nechci, aby tímto stylem další autoři programovali další programy a u toho se tímto stylem nestarali o to, jak to poběží jako služba. Protože toto je fakt pain provozovat a můžeme se jen hádat o tom, které řešení je horší. Jestli screen / tmux nebo celkem umělé napojení na fifo.

No vidíš a pro mě je důležitější čistota systému, než tam mít něco pro funkcionalitu, kterou lze řešit jinak.
Pro mne je důležitější mít funkcionalitu, než možnost, že by to teoreticky šlo řešit jinak – ale vyřešené to není.

To je jistě možné, ale otázkou je, proč tak neudělali doposud, když vstupní bariéra posledních 20 let vypadá přibližně tak, že při instalaci stačí několikrát odentrovat a je hotovo.
To právě není pravda. Instalací systému to nekončí. Pak bude chtít spustit svou službu – a narazí na ty init skripty.

Ano ale potom jsi tiše automaticky předpokládal, že se ten program bude chovat slušně. Ale to není automaticky splněno.
Ale taky to neznamená, že se tak chovají všechny programy, nebo jejich většina. To, že se programátor nestará o to, aby to běželo jako služba, neznamená, že se nezajímá o to, jak to poběží jako služba.

To právě není pravda. Instalací systému to nekončí. Pak bude chtít spustit svou službu – a narazí na ty init skripty.

Samozřejmě, že to instalací nekončí, hned po snadné instalaci může zkoumat systém, jak a proč a na jakých základech je to postaveno, prostě objeví celý nový svět. Proč by zase měl nutně chtít spouštět nějaké své služby? Bavili jsme se o tom, že "a někteří se budou chtít dozvědět víc".

Tohle je možná to, co je mi na dockeru asi nejvíc proti srsti. Ten přístup lidí. Že je tam možná nějaký linux, na to lidi kašlou (ne všichni), ale hlavně (jak píšeš), že mu tam jede jeho výtvor.

To, že se programátor nestará o to, aby to běželo jako služba, neznamená, že se nezajímá o to, jak to poběží jako služba.

Ok, tak pokud se zajímá o to, jak to poběží jako služba současně taky znamená, že si z hromady možností, jak ten program napsat a ovládat, vybere tu, která nejlépe umožňuje běh jako služba. To je u mě totéž, jako kdyby se staral, aby to běželo jako služba. Možná ne technicky (odpojením od řídícího terminálů a odforkováním), ale implementací určitě.

Bavili jsme se o tom, že "a někteří se budou chtít dozvědět víc".
Víc se budou chtít dozvědět, pokud s tím systémem vůbec budou chtít pracovat. A pracovat s ním budou chtít tehdy, pokud tam snadno zprovozní to, co potřebují.

Že je tam možná nějaký linux, na to lidi kašlou (ne všichni), ale hlavně (jak píšeš), že mu tam jede jeho výtvor.
No vždyť ano. Je to jen nástroj, který chtějí použít pro svoji práci – a když se jim osvědčí, budou ho třeba používat víc. Ty to možná vnímáš jinak, ale pro většinu lidí není operační systém na počítači to primární, je to pro ně jen nástroj, jak s počítačem dělat něco jiného.

Ok, tak pokud se zajímá o to, jak to poběží jako služba současně taky znamená, že si z hromady možností, jak ten program napsat a ovládat, vybere tu, která nejlépe umožňuje běh jako služba. To je u mě totéž, jako kdyby se staral, aby to běželo jako služba. Možná ne technicky (odpojením od řídícího terminálů a odforkováním), ale implementací určitě.
Pro mne je důležité to, aby ten program počítal tím, že u něj nebude sedět člověk. Takže ovládání přes readline nepovažuju za dobrý nápad. Ale jinak ty pokusy aplikací udělat ze sebe službu jsou spíš na škodu – právě jako to odpojení od řídícího terminálu a odforkování.

Ty to možná vnímáš jinak, ale pro většinu lidí není operační systém na počítači to primární, je to pro ně jen nástroj, jak s počítačem dělat něco jiného.

Ano, pro mě je velmi důležitá i ta GNU filozofie. Která se pomalu vytrácí. Dále je pro mě důležité vědět, že systémy lze stavět i způsobem unixu, tedy z malých jednoúčelových nástrojů postavit větší celek. Nic z toho nikdy nebude pro většinu lidí, ale pro někoho snad.

Pro mne k těm jednoúčelovým nástrojům, ze kterých lze postavit větší celek, patří i nástroje systemd.

> Tohle je možná to, co je mi na dockeru asi nejvíc proti srsti. Ten přístup lidí. Že je tam možná nějaký linux, na to lidi kašlou (ne všichni), ale hlavně (jak píšeš), že mu tam jede jeho výtvor.

A proc by na to nemeli kaslat? Kdyz chces stlouct dva ramy, zajima te jak se vyrabi kladivo, nebo je to proste jenom nastroj, ktery pouzijes ?:-)

Pochop, ze zejmena v komercni sfere nikdo nestoji o zadne "genialni" adminy bastlire, ale o unifikovane, standardni reseni.
A to je presne jeden z duvodu, proc se Docker tak dobre ujal a proc jej pouzivaji - protoze poskytuje presne tohle, na spravu jsou kontejnery mnohem jednodussi nez nejake vlastni bastleni / lepeni sluzeb na jeden VM ci dokonce fyzicky stroj.

> Ok, tak pokud se zajímá o to, jak to poběží jako služba současně taky znamená, že si z hromady možností, jak ten program napsat a ovládat, vybere tu, která nejlépe umožňuje běh jako služba. To je u mě totéž, jako kdyby se staral, aby to běželo jako služba. Možná ne technicky (odpojením od řídícího terminálů a odforkováním), ale implementací určitě.
A proc by mu pro implementaci nemelo stacit spustit se, nastartovat vlakna ktere potrebuje a osetrit standardni ukonceni programu? Presne takhle to totiz dela Kafka (+ ma navic i remote API, ale tj jedno).

Ono kdyz je program udelany takto, tak to bude fungovat vsude - jen v sysvinitu je potreba resit ojeby / spousteni pres dalsi programy (su,daemon,...)

A proc by na to nemeli kaslat? Kdyz chces stlouct dva ramy, zajima te jak se vyrabi kladivo, nebo je to proste jenom nastroj, ktery pouzijes ?:-)

No kupodivu zajímá, protože, světě div se, jsou různá kladiva pro různé účely a už jsem viděl někoho zatloukat hřebíky olověným kladivem určeného pro práci s měkkými kovy (aby nezanechávalo stopy po úderech).

A to je presne jeden z duvodu, proc se Docker tak dobre ujal a proc jej pouzivaji - protoze poskytuje presne tohle, na spravu jsou kontejnery mnohem jednodussi nez nejake vlastni bastleni / lepeni sluzeb na jeden VM ci dokonce fyzicky stroj.

Mno. Jenže všechen ten bordel se přesunul jen dovnitř, kde na něj není vidět. Neříkám, že to tak dělají všichni, ale co jsem měl tu čest vidět, jak lidé zacházejí speciálně s dockerem tak, že je to jen o tom to nějak zbaslit (stáhnout z náhodných zdrojů image, dát tam konkrétní verze knihoven apod.) aby to prostě jelo. Tady je obrovský potenciál pro bezpečnostní problémy do budoucna, protože se málokdo zajímá taky o to, že by se to mělo třeba upgradovat apod. (někteří vysloveně uvádějí, že za výhodu dockeru považují to, že tam budou mít stálé prostředí na věky věků od vytvoření až do smrti - toho kontejneru - a nějaké updaty os je zbytečně jen otravují).

A proc by mu pro implementaci nemelo stacit spustit se, nastartovat vlakna ktere potrebuje a osetrit standardni ukonceni programu?

A já jsem někde psal, že by mu to nemělo stačit? Ale pro to, aby to takhle někdo naimplementoval, tak nejdřív musí vědět, že tohle je vhodný způsob. Což ne vždy ví.