Názory k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL?

Fajn, a ten systemd je ve všech distribucích taky ve stejné verzi, ničím se neliší a má neměnné API? Něco mi napovídá, že to asi taky nebude úplně pravda.

Neni, ale tyto vlastnosti tu diskutovane ma od prvopocatku, takze na vsech verzich podporovanych dister to bude fungovat bez nutnych workaroundu ala su :)

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.

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á/archi­tektonická 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ů.

@Franta Kučera:
pro SoC desku (nebo docker kontejner!) může být plnohodnotný i EWONTFIX. A ten má dokonce jen pár desítek řá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.) ?

Ad „https://github­.com/systemd/sys­temd/tree/mas­ter/src/system­d“

Proč jsou v tom adresáři tedy soubory jako tyto? :-)

sd-dhcp-client.h
sd-dhcp-lease.h
sd-dhcp-server.h
sd-dhcp6-client.h
sd-dhcp6-lease.h
...
sd-ipv4acd.h
sd-ipv4ll.h
...
sd-radv.h
sd-resolve.h

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ě.

On spíš naráží na tu hrubku.

Mila redakce, ktere, z 8mi pravidel kultivovane debaty tu jsou naplneny? Warez a komerce?
Prave jsem tam navic nalezl tvrzeni, ze zeny jsou prumerne, nic nedokazaly a nechapaly.

ale pokud jste písmo "používaly", tak tím ze sebe zároveň děláš ženu.

Ne nutně, "používaly" je i pro střední rod, třeba ze sebe dělá dítě nebo nějaké jiné "to" :D

Jo pravda, děti jsou vlastně v plurálu ženský rod. Omlouvám se za chybu a ty si dej facku za chování.

Dneska již miliardy lidí používají písmo ale ne všichni jej používají k ukádání myšlenek.
Líbí se mi na umně maskovaná sebekritika ve vašem komentáři. První člověka napadne, že vy písmo k ukládání myšlenek nepoužíváte, ale pak si všimne, že k ukádání myšlenek vlastně ano.

Mas pravdu, jen par stovek serveru / VM, pak nejake Fedory 27, na laptopu Arch.

Očividně to nestačí...

Pokud se chces bavit konkretne, hod sem link na bugreport. Predpokladam, ze jsi to reportoval :-)

To jsem svého času zkoušel, vzhledem k bezradnosti těch, co to mají na starosti a tomu, že jsem si to vždycky nakonec nějak vyřešil sám to už nedělám, je to zbytečná ztráta času. A hlásit to přímo Poeteringovi? Vyřešit to tak, že to prohlásím za feature umím taky - opět zbytečná ztráta času.

Jinak je to na urovni jedna pani povidala.

To vaše určitě :)

Co se tyka sessions a systemd - jsou tam nejake zname stare (vyresene) bugy

Což dle vaší logiky vylučuje neznámé a nevyřešené... Jasně :)

Pro váš klid prohlašuji, že systemd je bezchybný, tahle diskuze s "idealistama", uzavřenýma ve svém výseku světa, kde jim to náhodou funguje a popírající stavy, kdy to prostě nefunguje je zbytečná. ;)

> To jsem svého času zkoušel, vzhledem k bezradnosti těch, co to mají na starosti a tomu, že jsem si to vždycky nakonec nějak vyřešil sám to už nedělám, je to zbytečná ztráta času. A hlásit to přímo Poeteringovi? Vyřešit to tak, že to prohlásím za feature umím taky - opět zbytečná ztráta času.

No tak sup, linky na bugreporty, kdyz jsi to zkousel :-)

> Pro váš klid prohlašuji, že systemd je bezchybný, tahle diskuze s "idealistama", uzavřenýma ve svém výseku světa, kde jim to náhodou funguje a popírající stavy, kdy to prostě nefunguje je zbytečná. ;)

Ja nejsem zadny idealista, me je SD celkem sumak, spoustu veci si dovedu predstavit, ze by delal jinak / lepe / ... Jen konstatuji to, ze pokud vis o nejakych chybach, tak je mas nareportovat.
Pokud jsi je nareportoval, neni nic jednodussiho nez poslat bugreporty.
Pokud jsou ty chyby tak bezne a nereportoval jsi je, jiste neni problem najit nejake bugreporty jinych.

Ja jsem si tu praci s googlenim problemu, co jsi popsal dal a nic potvrzujici tve tvrzeni jsem nenasel.
A nikde netvrdim, ze tam nezname bugy nejsou - zcela jednoznacne jsou (stejne jako v kernelu, glibc, OpenSSH, ....).

Tvrdis neco, pro co jsi neprinesl zadny dukaz. Stejne tak muzu prohlasit, ze LP znasilnuje male deti a upstart zpusobuje zaludecni vredy (i kdyz, s tim by mozna autor clanku souhlasil :-D), argumentacni kvalitu to ma uplne stejnou.

No tak sup, linky na bugreporty, kdyz jsi to zkousel :-)

Nechcete se zklidnit? Nejsem váš podřízený ani nemám potřebu pořád sedět na Rootu, popohánějte si někoho jiného.

Kdo chce, bugrepoty si najde, já už co se týká systemd nerepotuji, vzhledem k přístupu autora k řešení chyb i bezradnosti maintainerů. Čas je drahý, naučil jsem se si s tím poradit různými způsoby, které jsou výrazně rychlejší než zbytečné hlášení a vysvětlování, že to skutečně funguje, že jsem to co mi navrhují dávno vyzkoušel a že to nepomohlo a skončení ve stavu, že nevědí co s tím a nakonec, že to stejně nějak vyřeším sám a hotovo.

Vzhledem k vašemu povýšenému přístupu k diskuzi nepošlu, nemám zájem se s vámi zbytečně dohadovat a vyvracet vám vaše teorie, bez praktické zkušenosti.

Jen konstatuji to, ze pokud vis o nejakych chybach, tak je mas nareportovat.

To u systemd už nedělám, nemá to cenu. U jiných softů s tím problém nemám.

Tvrdis neco, pro co jsi neprinesl zadny dukaz.

Zato vy tvrdíte s důkazy, že? :D :D :D

Na zbytek vašeho příspěvku zbytečné reagovat (obzvlášť o znásilňování dětí, jen se snažíte dát svému prázdnému příspěvku váhu v silných slovech a emotivních nesouvisejících tématech).

> Zato vy tvrdíte s důkazy, že? :D :D :D
Ja jsem linkoval 2 bugreporty.
A obecne plati ze dukazni bremeno nese ten, jez neco tvrdi (v tomto pripade ty).
Chtit po jinych aby bez dukazu akceptovali nejake tvrzeni (navic odporujicich zkusenosti) je prinejmensim detinske.

> To u systemd už nedělám, nemá to cenu. U jiných softů s tím problém nemám.
To je tvoje svobodne rozhodnuti, nicmene pokud uz to nedelas a ty chyby, ktere jsi tu zminoval, jsi reportoval / nasel reportovane, tak neni opravdu nic jednodussiho nez postnout link :-)

> Na zbytek vašeho příspěvku zbytečné reagovat (obzvlášť o znásilňování dětí, jen se snažíte dát svému prázdnému příspěvku váhu v silných slovech a emotivních nesouvisejících tématech).

To je priklad argumenty / dukazy nepodlozeneho tvrzeni. Kdyz to vezmeme do dusledku, tak je to stejna situace jako diskuse o onech zasadnich chybach systemd s tebou - tvrzeni, ktere neni nicim podlozene.

Ja ti klidne verim, ze jsi se sd nejake problemy mel, ja je mel taky, ale to absolutne nevylucuje moznosti, ze
a) delas neco spatne
b) autor tve distribuce udelal neco spatne
c) je chyba v sd

Vetsina "chyb" sd, co jsem videl / cetl (vazici se napr. k zastavovani sluzeb) byla v dusledku zpusobena spatnymi .service a nikoliv chybou v samotnem sd. Tot moje zkusenost.
Ty jsi tvrdil neco jineho, ja po tobe chtel odkaz na bugreport (ktere jsem i sam zkousel hledat), ty jsi zadny nedostal a rozcilujes se, ze ti to neverim jen proto, ze to tvrdis :-) Tot ve strucnosti cela tahle diskuse.

A obecne plati ze dukazni bremeno nese ten, jez neco tvrdi (v tomto pripade ty).

Začínám mít pocit, že jste nějakým způsobem vyšinutý. Nejsme u soudu a nemám potřebu zrovna vám něco dokazovat. Už jsem vám jasně dal najevo, že o diskuzi s vámi nestojím, tak mi není jasné, co na tom nechápete a proč se mě do ní neustále snažíte zatáhnout. Ale možná to je jen projev toho, jak si z mých příspěvku vyberete co se vám hodí a "přehlížíte" zbytek, takže jste přehlídl i můj nezájem s vámi diskutovat potažmo vám něco dokazovat.

tak neni opravdu nic jednodussiho nez postnout link

"Nechci" pro vás není odpověď, že? Začínáte být otravný až vlezlý. Akceptujte prosím, že NECHCI, děkuji.

a rozcilujes se, ze ti to neverim jen proto, ze to tvrdis

1. Nerozčiluji se (proč taky, kvůli nějaké virtuální diskuzi po netu?)

2. Jestli mi to věříte nebo ne je mi úplně šuma fuk, takže jste i v tomto úplný mimoň, vaše neustálé mylné předpoklady, na kterých lpíte jako na axiomech jsou dost podstatnou chybou.

> Pokud srovnam dokumentaci systemd a v podstate skoro jakehokoliv sysvinitu z predchozich dob na Linuxu, tak mi z toho jednoznacne vychazi lepe systemd. Typicky init predtim byla smes bashovych funkci, povetsinou bez jakekoliv dokumentace.

To není pravda. Sys-V init je pouze infrastuktura která říká JAK se ty init skripty spouštějí. Vše si pak implementuje autor/maintai­ner/správce sám, a potřebuje na to znalost shellu, kterou tak jako tak doposud při práci v *nixu potřeboval. To že dokumentace obsahuje jen málo věcí neznamená, že tam je spousta nezdokumentovaných věcí. Ty v tom systému prostě nejsou, takže nepotřebují dokumentovat. A vzhledem k tomu, že ten systém se nesnažil vytlačit jiný systém, tak nepotřeboval dokumentaci běžných usecases. Místo toho existovala dokumentace k tomu jak se má chovat správný daemon (dvojitý fork, zavření stdin/stdout, ...) a považovalo se to za dokumentaci toho jak má být správně napsaná služba (nikoli za dokumentaci init systému). Systemd to bere na sebe, takže to musí zdokumentovat, a snaží se přebrat pod sebe i služby které byly napsané pro sys-V init. Takže by měl obsahovat dokumentaci správného přechodu těchto služeb. (Viz dokumentace upstartu a jeho expect fork.) To že se do stable verze tak velké distribuce jako je Debian dostane špatně napsaný service file pro tak klíčovou službu jako je ssh považuji za fail jak Debianu tak dokumentace systemd.

Ty v tom systému prostě nejsou, takže nepotřebují dokumentovat.
Viděl jste někdy nějaký rc skript? Zkuste se někdy na nějaký podívat, uvidíte, kolik tam je věcí – a zdokumentované obvykle není vůbec nic.

Netvrdím, že zdokumentovat nepotřebují. Naopak. Ale nejsou to věci o které se stará sysV init, takže to není chyba dokumentace sysV initu. Může to být chyba designu, ale není to chyba dokumentace.

Aha, takže SysVInit nedělá skoro nic, takže vlastně za nic nemůže. A ty skripty, co jsou okolo, aby to vůbec něco dělalo, ty se nepočítají, to jsou jen skripty.

Ano přesně tak. Někdo napsal SysV init kdysi velmi jednoduše, protože nechtěl/neměl sílu řešit co bude pod tím. A vznikl čurbes, se kterým se většina lidí naučila žít, a v leckterých distribucích ho i uměli docela dobře uklidit. (V debianu jsem se SysV init skripty neměl problém. Většina jich navíc používá společnou shellovou knihovnu.) Systemd sám o sobě je krokem vpřed (a často i stranou, ale o tom se teď nebavíme), ale způsob jeho zavádění je krok vzad.

> Pochopitelne, diky tomu, ze sysv init je smes bashovych skriptu, neda se zadnym zpusobem rozumne sparsovat (protoze to neni deklarativni konfigurace, ale imperativni zapis kroku), tak pochopitelne vsechny tyhle konverze jsou odsouzeny k zahube.

No a právě proto je lepší se nezkoušet dělat automatické konverze ale místo toho udělat rozumný sysVinit wrapper, který bude sysV emulovat dobře.

> No a právě proto je lepší se nezkoušet dělat automatické konverze ale místo toho udělat rozumný sysVinit wrapper, který bude sysV emulovat dobře.
Nebo nedelat zbytecnou praci s udrzovanim kompatibility s necim, co melo umrit uz davno, a proste to prevest na robustnejsi .service, jak to udelaly vsechny majoritni distribuce :-)

To prave lepsi neni, protoze to spousta majoritnich distribuci udelala spatne.

Prave proto, ze si "hraji na bezpecnostni firmu" neaktualizuji na nove (mozna nekompatibilni) verze jako blazni, ale pouzivaji stabilni, zaplatovanou verzi z podporovane verze distribuce :-)

Nejenom to, je i mnohem snazší takovou službu ladit – ať už jako vývojář, nebo jako správce. Spustím službu pod debugerem, z příkazového řádku nebo ze správce služeb, a pořád běží přesně stejně, vykonává se stejný kód.

To není 100% pravda. Například web-server na běžném OS pořebuje privilegium poslouchat na portu 80 (tedy menším než 1024). Takže musí nejdřív začít poslouchat a potom změnit uživatele.
To není pravda. Buď může mít proces capability pro naslouchání na privilegovaném portu, nebo mu může příslušný socket předat správce služeb.

Pak ale nastavím socket-activation službu a nevím, že je služba rozbitá, dokud se doopravdy něco nepokusí přistoupit na tu socketu.
To platí jedině v případě, kdy je ta služba odfláknutá. Když se ta služba bude chovat aspoň trochu rozumně, tak se v případě problémů ukončí.

A k čemu mi je správné ukončení když se ta služba ani nespustí? Já potřebuju aby ta služba byla funkční, což se nahrazením kofiguráků a případným reloadnutím systemd nedozvím, protože ke skutečnému spuštění a tedy přeparsování konfiguráků služby a vyhlášení chyby dojde až s prvním přístupem na socketu.

Pořád se tady píše o dobře napsaných službách a zodpovědném přístupu administrátora. Dobře napsaná služba má snad možnost ověření konfigurace nezávisle na spuštění, a zodpovědný správce tu možnost snad využije.

Navíc vám nikdo nebrání tu službu nastartovat hned.

@Jirsak 19:34
Ano, já se bojím nezodpovědného package-maintainera, který mi přesune službu na socket activation s dalším releasem distribuce. Že se to je rozbité zjistím, až škoda nastane.

ebik, 19:38: A co teprve když vám nezodpovědný package-maintainer v tom shellovém skriptu pro SysVInit smaže celý disk.

@Jirsak 19:44:
rika se nekrm trolla, ale nemuzu si pomoct:
nezodpovedny package maintainer prehodil sshd v debianu na systemd unitu forking. Tim ale vyradil kontrolu toho, ze sshd bude umet vytvorit listening socketu na portu 25. Systemctl (re)start sshd tvril ze je vse v poradku. Nicmene sshd nebezelo.

> nezodpovedny package maintainer prehodil sshd v debianu na systemd unitu forking. Tim ale vyradil kontrolu toho, ze sshd bude umet vytvorit listening socketu na portu 25. Systemctl (re)start sshd tvril ze je vse v poradku. Nicmene sshd nebezelo.
To je neprijemne. Ale jako je to poznatek na urovni toho, ze kdyz udela package maintainer krpu, muze to rozbit system. Stejne tak se dalo udelat milion jinych problemu v sysv initu. To je neresitelny problem.

> To je neprijemne. Ale jako je to poznatek na urovni toho, ze kdyz udela package maintainer krpu, muze to rozbit system. Stejne tak se dalo udelat milion jinych problemu v sysv initu. To je neresitelny problem.

Pouze do te doby, dokud je sam. V Debian Jessie je ale vadnych vice nez polovina service filu (subjektivni mereni, vychazejici z toho, ze 90% sluzeb ktere pouzivame ma v Debian jessie spatny service file, vetsinou to nevadi a naucili jsme se s tim zit, ale v nekterych pripadech to vede k jeste horsim chybam.)

> To není 100% pravda. Například web-server na běžném OS pořebuje privilegium poslouchat na portu 80 (tedy menším než 1024). Takže musí nejdřív začít poslouchat a potom změnit uživatele. Pokud ovšem za něj začne poslouchat správce služeb, tak se najednou musí správce služeb postarat, aby ta socketa měla nastavené vše co ten webserver potřebuje a musí rozumět síťovému stacku*. Spousta dalších služeb také potřebuje privilegovaný přístup k nějakým dalším prostředkům, ale jinak běžet neprivilegovaně. To se nejlépe řeší tím, že se jim poskytne API/ABI. Zvenčí to chce jen zajistit aby ta služba neměla přístup k věcem ke kterým mít přístup nemá. Na to mi v tradičním systému stačí code-review kódu před vzdáním se rootovských práv.

Proc to delat dobre, kdyz to jde delat uplne blbe, ze :)
Navic to neni absolutne pravda, existuje mnohem lepsi reseni (a dokonce nekolik) - pridat procesu capability (napr. poslouchat na privilegovanem portu), pak zadne prava roota nepotrebuje a muze bezete rovnou pod neprivilegovanym uzivatelem.
Doporucuji dostudovat POSIX Capabilities, je to docela uzitecne :)

Druhou moznosti je socket activation, ale to je trochu na neco jineho.

> * tohle autoři systemd řeší pomocí socket-activation. Pak ale nastavím socket-activation službu a nevím, že je služba rozbitá, dokud se doopravdy něco nepokusí přistoupit na tu socketu. V produkčním prostředí děkuji, ale nechci.

Socket activation totiz neni primarne urceny na reseni poslouchani na portu < 1024, ale pro sluzby, ktere nemaji bezet porad, ale jen tehdy, kdyz jsou potreba :) A samozrejme to ma dusledek ten, ze se ... sluzba spustti az tehdy, az je potreba.
Pro permanentne bezici sluzby je to nevhodne.

Btw, nemas na produkci healthcheck a monitoring? Spolehat na to,ze sluzba funguje, kdyz bezi proces - diky, ale to bych nechtel :)

> Btw, nemas na produkci healthcheck a monitoring? Spolehat na to,ze sluzba funguje, kdyz bezi proces - diky, ale to bych nechtel :)

Samozřejmě, že mám. Jen poukazuju na to, že na produkci vnáší socket-activation výrazně větší složitost do orchestračních nástrojů, protože když se orchestrační nástroj nedozví okamžitě, že tam nahrál syntakticky špatný konfigurák, tak se z používání takového orchestračního nástroje administrátor téměř okamžitě zblázní.

> Samozřejmě, že mám. Jen poukazuju na to, že na produkci vnáší socket-activation výrazně větší složitost do orchestračních nástrojů, protože když se orchestrační nástroj nedozví okamžitě, že tam nahrál syntakticky špatný konfigurák, tak se z používání takového orchestračního nástroje administrátor téměř okamžitě zblázní.
Tak ho nepouzivej, je to feature primarne pro desktop a obcas bezici sluzby :) Na permantne bezici sluzby to neprinasi temer zadne vyhody.

Je to stejna situace jako za davny casu s inetd - uplne ten stejny problem, uplne ty stejne issues, to je dane principem celeho reseni.

Ano, ale inetd neni soucasti initu a package maintainera nebo vyvojare nenapadne ze by byl "dobry napad" to napsat pomoci socket activation.

Zatraceně, vytratila se mi pointa. A navíc jsem si tu manpage přečetl napoprvé špatně, protože je ta manuálová stránka napsaná tak aby bylo jasné jak se řeší SUID bit na souboru. Tady jsme ale v jiné situaci.

Přijde mi, že capabilities je pěkný systém jak udělat hardening, ale stále mi nerozliší, že uživatel www-data-4 smí poslouchat jen na 1.2.3.4:80 a uživatel www-data-5 jen na 1.2.3.5.80. Takže stále musím věřit aplikaci, že si vezme ten správný resource. A pokud neobsahuje linux-specifický kód tak se práva CAP_NET_BIND_SER­VICE umí vzdát jen jediným způsobem: změnou uživatele z roota na neroota. Vůbec se neodvažuji tady pomyslet na aplikace, které se práv po inicializaci nevzdají, jen proto, že "už jich přece nemají tolik, tak proč to řešit".

Pokud budete chtít z tohoto důvodu CAP_NET_BIND_SER­VICE aplikaci vůbec nedat, potřebujete aby váš init systém uměl rozumět prostředkům, které té službě předává (listen socketa na port 80), to už není moc KISS, a vždy přijde někdo s další třídou prostředků, které je do toho potřeba doimplementovat. Tohle by bylo hezké, kdyby to bylo řešeno jako obecná rozšiřitelnost, a ne jen řešení jednoho konkrétního případu (síťový subsystém).

Pokud bude mít aplikace linux-specifický kód, starající se o inicializaci (zahození CAP_NET_BIND_SER­VICE), tak už mě neuráží, že se má starat i o to, aby správně běžela v historickém sys-V initu. A pokud pak systemd vyžaduje jinou sekvenci spouštění, má ji vyžadovat, místo toho aby tvrdil, že takovou aplikaci (napsanou pro sysV) umí spustit bez ztráty spolehlivosti spuštění.

Vůbec se neodvažuji tady pomyslet na aplikace, které se práv po inicializaci nevzdají, jen proto, že "už jich přece nemají tolik, tak proč to řešit".
Právě proto je dobré mít moderního správce služeb. Pak v té aplikaci nemusíte mít žádný kód specifický pro linux, nespouštíte jí pod rootema nemusíte se spoléhat na to, že se vzdá práv. Prostě jí spustíte pod správcem služeb, který se vzdá nepotřebných capabilit, změní uživatele a pak svůj proces nahradí procesem služby.

potřebujete aby váš init systém uměl rozumět prostředkům, které té službě předává (listen socketa na port 80)
Ne, nepotřebujete, viz popis výše. Už to tu popisuju podruhé, tak to snad konečně vezmete na vědomí.

@Jirsak 19:42
> Ne, nepotřebujete, viz popis výše.
Tak teď si přímo protiřečíte. Pokud nerozumí prostředkům, tak se nemůže vzdát capabilit na získání těch prostředků, a pak spustit aplikaci. Jak by se ta aplikace k těm prostředkům dostala? Buď nechá capability na získání těch prostředků aplikaci, ať se jich vzdá sama po inicializaci, nebo umí ty prostředky pro tu aplikaci obstarat. Pokud je umí obstarat, tak jim rozumí.

ebik, 19:57: Jenže on se nevzdává capabilit pro získání těch prostředků, vzdává se všech ostatních capabilit. Že by se vzdal i té capability pro získávání potřebných prostředků je velmi výjimečný případ a linux pro to holt prostředky neposkytuje. Asi by se to využilo jen pro tu capabilitu naslouchání na privilegovaných portech, navíc u aplikací, u kterých není možné obnovit konfiguraci za běhu. Navíc chyba, že by aplikace začala nečekaně naslouchat někde, kde nemá, je dost nepravděpodobná a ne moc nebezpečná.

@Jirsak, 20.1. 21:21
> Že by se vzdal i té capability pro získávání potřebných prostředků je velmi výjimečný případ
Tak to ani omylem. Většina serverů co znám, tak má master proces, který jenom spawnuje "workery" (nebo jen jednoho workera). Ten master server si ponechává roota a získává prostředky, a ty workeři již na získání dalších prostředků práva nemají.

>Navíc chyba, že by aplikace začala nečekaně naslouchat někde, kde nemá, je dost nepravděpodobná a ne moc nebezpečná.
Nebezpečné je pokud se aplikace (díky například buffer overflow nebo underrun) zmocní útočník. Může aplikaci přinutit poslouchat třeba na portu 22 (pokud předtím odstřelil ssh, třeba oom killem) jen proto, aby získal víc času. Nebo na nějakém jiném portu (třeba na portu LDAPu, aby odchytil přihlašovací hesla do legacy systémů napojených na LDAP). A zrovna třeba webservery jsou tak častým případem serverů, že někdo neustále hledá nějakou jejich zranitelnost.

@ebik 8:49
Zapoměl jsem dopstat, že master proces se stará pouze o konfiguraci a inicializaci. Takže je jen malá šance, že ho chyba ve workeru nějak ovlivní. Naopak workeři dělají veškerou práci, takže téměř celý attack surface je na workerech a ne na masterovi.

> Zapoměl jsem dopstat, že master proces se stará pouze o konfiguraci a inicializaci. Takže je jen malá šance, že ho chyba ve workeru nějak ovlivní. Naopak workeři dělají veškerou práci, takže téměř celý attack surface je na workerech a ne na masterovi.

Porad mnohem vetsi nez pokud ten maste proces ty root prava vubec nema.
Takze attack surface je zde mnohem vetsi nez v pripade, ze master proces pod rootem nebezi, ma jen extra cap na poslouchani. A pokud se k tomu prida SELinux policy, ktera omezi na kterych portech muze poslouchat, tak tu tenhle attack surface mizi uplne.

@tnr 22.1. 12:33:

Kdybyste cetl pozorne, tak resim situaci, kdy se server vzda privilegii mezi masterem a workerem. Jestli ty privilegia ma formou roota nebo capabilities neni podstatne. Roota jsem pouzil proto, ze ty projekty jsou starsi nez specifikace capabilities.

ebik , 8:49: Takže vy master procesu raději necháte roota, než abyste ho nechal běžet pod obyčejným uživatelem a ponechal mu jenom capability pro naslouchání na privilegovaných portech. Pak nechápu, co tady řešíte, když sám dobrovolně používáte daleko nebezpečnější variantu.

@Filip Jirsak 22.1. 8:57:
O to tady nejde. Rozporoval jsem tvrzeni ze se ty aplikace(servery) nevzdavaji privilegii po inicializaci.

> Tak to ani omylem. Většina serverů co znám, tak má master proces, který jenom spawnuje "workery" (nebo jen jednoho workera). Ten master server si ponechává roota a získává prostředky, a ty workeři již na získání dalších prostředků práva nemají.

Jop, presne, ponechava si roota, protoze .... musi :-D A ten mu zustane, takze jakakoliv chyba tam je skutecne zasadni prusvih (protoze child procesy typicky s master procesem nejak komunikuji).
S capabilities se tam root vubec neobjevi, tudiz moznosti zneuziti jsou vyrazne mensi (navic muze mit capabilities opravdu hodne osekane, tudiz nemusi mit ani ty standardne dostupne pro neprivilegovaneho uzivatele).

> Nebezpečné je pokud se aplikace (díky například buffer overflow nebo underrun) zmocní útočník. Může aplikaci přinutit poslouchat třeba na portu 22 (pokud předtím odstřelil ssh, třeba oom killem) jen proto, aby získal víc času. Nebo na nějakém jiném portu (třeba na portu LDAPu, aby odchytil přihlašovací hesla do legacy systémů napojených na LDAP). A zrovna třeba webservery jsou tak častým případem serverů, že někdo neustále hledá nějakou jejich zranitelnost.
Zase, tohle resi SELinux policy. Pak muze daemon poslouchat jen na tech portech, na ktere ma skutecne pravo a na zadnem jinem.

> Jop, presne, ponechava si roota, protoze .... musi :-D

Musely v dobe pred capabilities. Bylo by ale demenci toto chovani (vzdani se prav ve workerovi) zahodit, kdyz uz je to jednou napsane. Navic to ze ma aplikace roota, NEZNAMENA, ze ma vsechny capabilities. Pokud jsem cetl manualovou stranku dobre, tak se lze snadno JAKO ROOT vzdat nekterych capabilities (a nemoct je pak ziskat zpet), a naopak zmenou uzivatele na neroota prijdu o VSECHNY capabilities, ktere normalni uzivatel nema (i pravo poslouchat na portu 80).

ebik 9:24: proč tu pořád opakujete ty vaše nesmysly, když vám tu minimálně dva lidi vysvětlili, jak to je? Tak ještě jednou. S moderním správcem služeb to funguje tak, že správce služeb vytvoří pod rootem nový proces (stále je to proces správce služeb), ten se následně zbaví nepotřebných capabilit, nastaví limity, změní uživatele na neprivilegovaného a na závěr proces nahradí procesem spouštěné služby. Proces spouštěné služby se tedy spouští pod neprivilegovaným účtem a práva roota nikdy nemá, má např. capabilitu pro naslouchání na privilegovaném portu (pokud ji správce systému v konfiguraci té služby povolil) a o capabilities nemusí vědět vůbec nic. Poku do nich něco ví, může se při spouštění workeru vzdát i té capability pro naslouchání na privilegovaném portu.

Takže rozdíl v tom vašem přístupu a přístupu moderních správců služeb je v tom, že vy spouštíte řídící proces s právy roota a doufáte, že se jich alespoň při spuštění workeru vzdá, zatímco moderní správce služeb spustí i ten řídící proces s omezenými právy. Přestaňte tedy prosím pořád vykládat o tom, jak je strašně výhodné spouštět proces s právy roota, i když je vůbec nepotřebuje. Výhodné to není, je to nebezpečné.

> Ano máme. A jsou linux-specifické. Takže tam kde jsme měli portabilní programy (SysV není jen linuxová záležitost), tak se nic nezměnilo (alespoň dokud se nenašel někdo komu by se to chtělo portovat). A tam kde programy portabilní nebyly tak je to jedno, stejně mají linux specifický kód. Jesli se v něm volá libdaemonize nebo libsystemd je mi šumák.

Linux specificke? Proc se jim rika POSIX Capabilities tedy? Ano, puvodni POSIX draft 1003.1e je stazeny, ale tj celkem fuk, Linux neni jedina implementace.
Navic i kdyby byla, je to jedno, viz nize.

> Přijde mi, že capabilities je pěkný systém jak udělat hardening, ale stále mi nerozliší, že uživatel www-data-4 smí poslouchat jen na 1.2.3.4:80 a uživatel www-data-5 jen na 1.2.3.5.80. Takže stále musím věřit aplikaci, že si vezme ten správný resource. A pokud neobsahuje linux-specifický kód tak se práva CAP_NET_BIND_SER­VICE umí vzdát jen jediným způsobem: změnou uživatele z roota na neroota. Vůbec se neodvažuji tady pomyslet na aplikace, které se práv po inicializaci nevzdají, jen proto, že "už jich přece nemají tolik, tak proč to řešit".

Na tohle neslouzi caps, ale selinux policy, ta presne resi, ze program X muze poslouchat na portu Y a zadnem jinem.

> Pokud budete chtít z tohoto důvodu CAP_NET_BIND_SER­VICE aplikaci vůbec nedat, potřebujete aby váš init systém uměl rozumět prostředkům, které té službě předává (listen socketa na port 80), to už není moc KISS, a vždy přijde někdo s další třídou prostředků, které je do toho potřeba doimplementovat. Tohle by bylo hezké, kdyby to bylo řešeno jako obecná rozšiřitelnost, a ne jen řešení jednoho konkrétního případu (síťový subsystém).

Vubec ne, zakladem je to, ze program pod root uzivatelem vubec nespustim, spustim ho jako neprivilegovany uzivatel (tzn. to, kam se dostane bezny sysv daemon) + navic mu dam urcite specificke caps navic. A nebo mu caps i normalniho neprivilegovaneho uzivatele jeste odeberu.

> Pokud bude mít aplikace linux-specifický kód, starající se o inicializaci (zahození CAP_NET_BIND_SER­VICE), tak už mě neuráží, že se má starat i o to, aby správně běžela v historickém sys-V initu. A pokud pak systemd vyžaduje jinou sekvenci spouštění, má ji vyžadovat, místo toho aby tvrdil, že takovou aplikaci (napsanou pro sysV) umí spustit bez ztráty spolehlivosti spuštění.

Prave ze ta aplikace nemusi mit vubec zadny linux specific kod. Muze byt napsana v ANSI C, stejne zdrojaky muzou fungovat na FBSD, Linuxu, Windows, Darwinu, ....

Proste a jenom se udela .service, v ni definuje pod jakym uzivatelem to ma bezet, prip. jak se omezi capabilities (prip pridam dalsi caps na binarku pres setcap). A ten program se nemusi starat vubec o nic. Je to lepsi, bezpecnejsi a jednodussi.

> Pokud bude mít aplikace linux-specifický kód, starající se o inicializaci (zahození CAP_NET_BIND_SER­VICE), tak už mě neuráží, že se má starat i o to, aby správně běžela v historickém sys-V initu. A pokud pak systemd vyžaduje jinou sekvenci spouštění, má ji vyžadovat, místo toho aby tvrdil, že takovou aplikaci (napsanou pro sysV) umí spustit bez ztráty spolehlivosti spuštění.

No a nebo se toho prava nevzda. S nastavenim caps v serivce nemuze v systemu nic, diky SELinuxu muze akorat znovu... poslouchat na svem portu :)
A nezasvini se kod platformne specifickymi vecmi.

Jednoznacn mnohem lepsi reseni nez to, co delaji daemony diky sysv - seteuid (cimz se rozhodne nezbavi vsech caps, ale pouze tech, ktere jsou navic dane root uzivateli oproti jinemu).

Tak si čtu nějaký tutorial o JAVA NIO a... jako céčkař mám pocit, že jsem skoro doma :-D akorát jakoby mi pořád něco unikalo... nějaká krása nahého těla nebo co... omluva za OT. Opět :-)

Tak doporucuju jeste mrknout na asynchronni IO v nodejs a pri dalsim psani epoll smycky nezustane jedno oko suchy :-)

Vetsi soubory to podporuje, jen potreba vice nez jeden MappedByteBuffer.
Ale souhlas, je to zbytecne omezujici, meli by to spravit.

U Kafky i Hadoopu ano. HDFS je filesystem nad filesystemem (ext4 napr.), jako HDFS se chape cely ten distribuovany FS, nikoliv jen to, co je ulozeno lokalne v souborech.

Vylepsilo, protoze sluzba nemusi resit jak se ma spustit, nemusi resit dropovani privilegii, nemusi se v ni konfigurovat logging (zvlast u jednodussich sluzeb), funguje to jak v spravci sluzeb, tak treba v dockeru.
A je treba rozdelit:
1) Spousteni / zastaveni sluzeb - coz je odpovednost spravce sluzeb
2) Akce ve sluzbe - na coz muzu mit CLI program, pokud ho dana sluzba potrebuje (spousta sluzeb nepotrebuje, jine sluzby zase potrebuji tyto akce mit dostupne jako REST, jine z command line, moznosti je mraky...)

Ten logging bych dvakrát nezmiňoval. Protože pokud chce služba logovat do souboru někam k sobě přesměrováním standardního výstupu, jediná možnost je spouštět ji přes shell, což není zrovna optimální.

Takže nakonec to musí zase řešit služba sama. A přitom by stačilo přidat jednu konfigurační položku, vedle těch stávajících. Místo toho raději integrujeme DNS, web server, NTP a plno dalších hovadin.

Vylepšilo se to, protože systemd pro komplexní komunikaci se službou využívá D-Bus (to je ta univerzální knihovna). systemd si pak může pře D-Bus povídat s aplikací o tom, jestli je schopná poskytovat služby, a někdo jiný si s tou aplikací může povídat třeba o tom, že má znovu načíst konfiguraci.

> 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.