Názory k článku
Debian bez systemd je za dveřmi: Devuan 1.0 RC2

Povedal by som, že ak netušíte, prečo démonizácia začína forkom, bude technologická diskusia s Vami zážitkom ktorému by som sa radšej vyhol.

Rovnak tak odporúčam premýšľať prelúskať si manuál k systemd.service, zistíte tak, ako veľmi sa môže líšiť spustenie pod SystemD od normálneho. Len tie premenné prostredia vie ovplyvniť asi 20 nastavení. Vedľa nich existujú i vlastné premenné SystemD, nastavenia plátne i pre iné typy jednotiek a premenné popisujúce predávané​ file desktriptory.

Zreprodukovať to všetko pri ladení v shelly je, myslím, ešte stále nemožné.

Povedal by som, že ak netušíte, prečo démonizácia začína forkom, bude technologická diskusia s Vami zážitkom ktorému by som sa radšej vyhol.
Já jsem ale nepsal, že netuším, proč démonizace začíná forkem – naopak po pořádném přečtení mého komentáře zjistíte, že to dobře vím. Psal jsem o tom, že je špatně, že se proces démonizuje, aby se dostal z dosahu svého rodiče, a běží pak způsobem, při kterém se velmi těžko ladí a vůbec zjišťuje jeho stav. Považuju za normální, že proces spustím, proces vypisuje informace na standardní výstup a chyby na standardní chybový výstup, já se na ně kdykoli můžu podívat, rodičovský proces může ten spuštěný proces ovládat tak, že mu pošle signál, a také se rodičovský proces dozví o ukončení procesu. Takhle to funguje, když službu spustím z shellu, a považuju za správné, že to úplně stejně funguje i tehdy, když proces spustím přes správce služeb.

Rovnak tak odporúčam premýšľať prelúskať si manuál k systemd.service, zistíte tak, ako veľmi sa môže líšiť spustenie pod SystemD od normálneho. Len tie premenné prostredia vie ovplyvniť asi 20 nastavení. Vedľa nich existujú i vlastné premenné SystemD, nastavenia plátne i pre iné typy jednotiek a premenné popisujúce predávané​ file desktriptory.
Abych pravdu řekl, nikdy jsem neřešil problém, že by služba používala nějaké proměnné prostředí, které defaultně nastavuje systemd. Naopak už jsem řešil spoustu chyb v init skriptech pro SysVinit, kdy při spuštění z shellu skript fungoval, ale pak při spuštění při startu nefungoval, protože byla jinak nastavená proměnná PATH nebo HOME.

Předávané deskriptory jsou věc navíc, SysVinit nic takového neuměl.

Zkuste si třeba ladit nějaké chyby při startu Apache. Když spustíte v shellu ten příkaz, který najdete v init skriptu, Apache se vám odforkuje a nevíte nic. Když ho chcete spustit v shellu, musíte použít parametr -x, a to najednou Apache dělá úplně něco jiného, než když běží z init skriptu. Ono je vůbec úžasné celé apachectl. Proč to programují autoři webového serveru? Neměl by se o tohle náhodou starat správce služeb?

> Abych pravdu řekl, nikdy jsem neřešil problém, že by služba používala nějaké proměnné prostředí, které defaultně nastavuje systemd.

Je to poznat :) Zial, to, ze ste sa Vy s takym problemom nestretol je ako riesenie dost nedostatocne.

> Předávané deskriptory jsou věc navíc, SysVinit nic takového neuměl.

SysVinit je init, neexistuje ziadny dodvod, preco by nieco take vediet mal. Ostatne, to neexistuje ani pre SystemD. Pre pouzitie, s ktorym ta funkcia bola povodne uvedena sa pouziva inetd.

> Proč to programují autoři webového serveru? Neměl by se o tohle náhodou starat správce služeb?

Spravca sluzieb kludne. Ved napokon, moje apache sa spusta z normalneho skriptu, avsak volanim na spravcu - start-stop-daemon -S -b -m -p /run/httpd.pid -x /usr/bin/httpd -- -k start -DFOREGROUND

Nie kazdy ale potrebuje k blbej LAMPe pustat spravcu sluzieb a uz vobec by sa o to nemal starat init.

Zial, to, ze ste sa Vy s takym problemom nestretol je ako riesenie dost nedostatocne.
Která proměnná prostředí, kterou vám systemd zákeřně nastavuje, dělá vaší aplikaci problémy? PATH nebo LANG?

Spravca sluzieb kludne. Ved napokon, moje apache sa spusta z normalneho skriptu, avsak volanim na spravcu - start-stop-daemon -S -b -m -p /run/httpd.pid -x /usr/bin/httpd -- -k start -DFOREGROUND
SysVinit na všechno stačí, je to jen obyčejný shell skript – a pak tam najednou navíc potřebujete start-stop-daemon s 5 parametrama.

Normální server, který dělá jen svou práci a nemusí suplovat správce služeb, se spouští příkazem /usr/bin/server z shellu, a ze správce služeb se překvapivě spouští tím samým příkazem /usr/bin/server. Není žádný rozumný důvod, proč by to mělo být jinak. Nerozumným důvodem je rozbitý správce služeb.

Nie kazdy ale potrebuje k blbej LAMPe pustat spravcu sluzieb
Pokud to nechce spouštět ručně z terminálu, ale automaticky jako službu, pak správce služeb potřebuje.

uz vobec by sa o to nemal starat init
V případě systemd se o to také init nestará. Systemd init toho dělá méně, než SysVinit init.

> V případě systemd se o to také init nestará. Systemd init toho dělá méně, než SysVinit init.

SystemD je monolit. Ak Vam niekto niekedy povedal nieco ine, znamena to len, ze sa z neho nikdy nepokusil vysekat jeden komponent.

> SysVinit na všechno stačí, je to jen obyčejný shell skript – a pak tam najednou navíc potřebujete start-stop-daemon s 5 parametrama.

Nepotrebujem, chcem :) Ale pravdupovediac, toto vzniklo skriptom, co prevadza SystemD unity na normalne skripty. Dalo by sa to prepisat aj na cisty bash, ale v podstate na to nikdy nebol dovod...

> Není žádný rozumný důvod, proč by to mělo být jinak. Nerozumným důvodem je rozbitý správce služeb.

Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb. Pokial podporuje beh ako demon, je to samozrejme plus.

> Pokud to nechce spouštět ručně z terminálu, ale automaticky jako službu, pak správce služeb potřebuje.

Neviem, ci sa da skript, co pri inicializacii systemu nahadzuje apaca nazvat spravcom sluzieb, ale nieco na tom bude :D

Kazdopadne, citajuc toto vlakno zacinam premyslat, ako sme to tych 30 rokov pred vynalezom SystemD vobec dokazali fungovat. Tolko problemov, co priniesol^H^H vyriesil, tolko use cases, co sme ani nevedeli, ze potrebujeme...

Skutocne je zazrak, ze na svete existuje tolko masin schopnych bez SystemD normalne fungovat.

> ale podil linuxu na desktopu taky o necem mluvi ))

O niecom konkretnom, alebo sa len snazis naznacit, ze BFU tusi nieco o inite? :)

> Sysvinit a treba podpora dynamicky pridavaneho hw, skoda mluvit.

To rozhodne. Rovnako ako je skoda hovorit o sysvinite a podpore prevodu reci na text.

> A na takove veci je marna slava ten systemd lepsi, protoze je unifikovany, ma api, funguje stejne na vsech distribucich...

Jediny problem je, ze systemd nieje unifikovany a nefunguje rovnako na vsetkych distribuciach. SystemD unit pre rhel nemusi bezat korektne na Archu a Archovske unity celkom urcite nebezia OK na Debiane.

A to je len jeden z prikladov problemov, ktore SystemD vynasiel, vyhlasil za nutne riesit a nevyriesil :D

Dej priklad unity, ktera je nekompatibilni.
Předpokládám, že největší problém bude v názvech – když si jedna distribuce pojmenuje službu httpd a druhá apache, nebudou závislé unity v jedné nebo druhé distribuci fungovat. (Což samozřejmě není problém jen systemd, nebude to fungovat nikde, kde se v závislostech používají arbitrární jména.)

> Viz vsemozne, neresitelne problemy napr. bez logind.

Vychadzajuc z toho, ze logind nemam na ziadnom zariadeni, ake neriesitelne problemy sa ma tykaju?

> Me to funguje docela dobre :)

To je mimoriadne relevantne :)

> A proc teda vubec treba vyvojar Archlinuxu rika, ze jim systemd vyrazne ulehcil praci pri sprave unit?:)

Pretoze pred prechodom na SystemD podporoval Arch niekolko init systemov. Pri prechode sice vyhlasili, ze pouzivaniu inych initov nebudu nijak branit, subory pre ostatne inity ale odstranili z balickov.

> Dej priklad unity, ktera je nekompatibilni

https://git.archlinux.org/svntogit/community.git/tree/trunk/0001-debian-ARCHLINUX-use-alternate-snap-mount-directory.patch?h=packages/snapd

Len prva vec co vyplul vyhladavac :)

> To je mimoriadne relevantne :)

Co take?

> Napr. stabilni ukonceni sezeni jednoho, vicenasobne prihlaseneho uzivatele, se vsemi procesy z tohoto sezeni (vcetne forknutych)

Inak povedane, slavny SystemD bug vrazdiaci procesy screenu a tmuxu. Na jednej strane chapem, ze naskriptovat toto by zabralo mozno i 5 riadkov, pritom ale nemam pocit, ze by zrovna toto bola ziadana featura :D

> A priklady neresenych problemu v tradicnim initu je mnohem vic - napr. aktivace sluzeb pridanim zarizeni (+ sprava zavislosti sluzeb v tomto pripade)

ATTRS{vendor}=="ni­eco" ATTRS{model}=="ni­eco-ine" RUN+="service start nejaka-sluzba"

To hadam ani nebolo myslene vazne :)

> Tzn. konfiguracni zmena cesty v unite je duvod, proc jsou ty jednotky nekompatibilni, to je rozhodne srovnatelne s nutnosti bastleni vlastnich init.d skriptu :)

Nie. Nutnost bastlenia si vlastnych jednotiek je zrovnatelne s nutnosti bastleni vlastnich init.d skriptu. Jednotka nekompatibilna kvoli ceste je zrovnatelna s init skriptom nekompatibilnym kvoli ceste. Skratka, vobec nic sa nezmenilo.

> Cituji 2brainz (vyvojar zodpovedny za init v Archu v te dobe):

To bol samozrejme krasny predpoklad a je smutne, ze mu nevysiel. Neprijemne je, ze si kvoli nemu "ulahcil" pracu i zrusenim podpory ostatnych initov.

SystemD je monolit. Ak Vam niekto niekedy povedal nieco ine, znamena to len, ze sa z neho nikdy nepokusil vysekat jeden komponent.
Mícháte hrušky a jabka. Jedna věc je unixová filozofie, že jeden proces dělá jen jednu věc – jak to dělají třeba jednotlivé komponenty qmailu, Postfixu nebo právě systemd. systemd PID 1 se pokud vím stará jen o spuštění správce procesů a o zombie procesy. Míň už toho PID 1 dělat nemůže.

Druhá věc je, že máte nějaký softwarový balík, který se skládá z většího množství komponent, které navzájem spolupracují. Vysekat jednu náhodně vybranou komponentu z qmailu nebo Postfixu také nebude snadné. Ale tak je to v pořádku – ty komponenty si navzájem poskytují nějaké služby, a pokud někdo chce nějakou komponentu nahradit, musí nahradit ty funkce, které ostatním poskytuje. Nemá smysl omezovat funkcionalitu jenom proto, aby nevznikla závislost na nějaké další komponentě. Většina lidí chce software používat kvůli jeho funkcím, ne pro to, aby měl co nejméně závislostí.

Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb.
Který server očekává konkrétního správce služeb? Tedy pokud vynecháme třeba Apache, který očekává nemožného správce služeb, takže si radši implementuje vlastní správu, nebo Postfix, který rovněž očekává nemožného správce služeb, takže si raději implementuje vlastního správce, nebo qmail, který toho vlastního správce rovnou zveřejnil jako samostatnou aplikaci.

Pokial podporuje beh ako demon, je to samozrejme plus.
Já v tom žádné plus nevidím, pro mne je to akorát komplikace a možný zdroj chyb.

Kazdopadne, citajuc toto vlakno zacinam premyslat, ako sme to tych 30 rokov pred vynalezom SystemD vobec dokazali fungovat.
To, že jsme nějak dokázali fungovat, neznamená, že to nejde lépe. Taky jsme dokázali fungovat bez internetu, bez elektřiny, bez vodovodu, bez domů.

tolko use cases, co sme ani nevedeli, ze potrebujeme...
To je podobné jako s IPv4. Taky si mnozí nedokážou představit, k čemu je dobré mít všude veřejné IPv6 adresy, a neustále pláčou nad tím, že jim přestanou fungovat jejich rovnáky na vohejbáky na obcházení NATu. Pravda je, že u veřejných IP adres je to ještě pikantnější, protože internet tak dlouhá léta fungoval, takže tam to ani není posun vpřed, ale jenom návrat k lepšímu stavu, který už jsme dříve měli.

> Jedna věc je unixová filozofie, že jeden proces dělá jen jednu věc

... mountuje filesystémy, spravuje konzole, vypočítava machine_id (nech je to čokoľvek), parsuje stringy v kernel commandline, prehadzuje procesy medzi jadrami cpu, číta konfiguračné súbory, reštartuje procesy, zapisuje container_id a vypisuje help. A to som prosímpekne prešiel v tom zdrojáku len do polovice, než ma to prestalo baviť.

Pre porovnanie si pozrite init skript runit-u, ktorý ma, keď zrátam všetky 3 stages, 200 riadkov shellu.

> <i>Normalny server hlavne nema ocakavat pritomnost dakeho spravcu sluzieb. </i>
> Který server očekává konkrétního správce služeb?

Kde sa zrazu vzalo to "konkrétního" ? :)

> To, že jsme nějak dokázali fungovat, neznamená, že to nejde lépe.

S tým náhodou súhlasím. Čo mne osobne vadí je, že sme miesto "lépe" prešli na "komplikovanejšie". SystemD ako správca služieb docela obstojí, ale už v dobe, keď ešte len crashoval inštalácie nás, odvážlivcov s Archom, existovali oveľa zaujímavejšie riešenia. Ruinit Voidu, OpenRC riešiaci všetky problémy, ktoré SystemD pôvodne riešiť mal na ~100 riadkov shellu, InitNG ktorý neriešil nič, ale dokázal nabootovať Arch pod 5 sekúnd a pár ďalších čo im neviem prísť na meno.

Každý z nich je schopný nahradiť klasický init jedným príkazom na správcu balíčkov a zvyšok systému o tom ani netuší. Preto sa radšej prešlo na obludnosť, čo pokladá za vhodné kompletne redefinovať ako sa operačný systém správa :)

... mountuje filesystémy, spravuje konzole, vypočítava machine_id (nech je to čokoľvek), parsuje stringy v kernel commandline, prehadzuje procesy medzi jadrami cpu, číta konfiguračné súbory, reštartuje procesy, zapisuje container_id a vypisuje help. A to som prosímpekne prešiel v tom zdrojáku len do polovice, než ma to prestalo baviť.
Aha, tak vy jenom nevíte, co je to proces.

Kde sa zrazu vzalo to "konkrétního" ? :)
Předpokládal jsem, že to tam patří, aby to tvrzení vůbec dávalo nějaký smysl. Co by podle vás znamenalo, že server očekává nějaký libovolný správce služeb? Že by bez nějakého libovolného správce služeb ani nešel nastartovat? A jak by ten server potom nastartoval nějaký libovolný správce služeb?

Čo mne osobne vadí je, že sme miesto "lépe" prešli na "komplikovanej­šie".
To už tak většinou je, že „lépe“ znamená „komplikovaněji“. Kdyby „lépe“ znamenalo jednodušeji, tak už to tak děláme dávno, protože by nebyla potřeba ta doba nutná ke zvládnutí toho komplikovanější. Auto je komplikovanější než žebřiňák, a žebřiňákem a ne autem jsme začli proto, že je to jednodušší a bylo potřeba nějaký čas, než jsme zvládli udělat něco tak komplikovaného, jako je auto. Stejně tak postavit dům je komplikovanější, než najít jeskyni, ale opět trvalo nějakou dobu, než jsme se to naučili.

OpenRC riešiaci všetky problémy, ktoré SystemD pôvodne riešiť mal na ~100 riadkov shellu
Jak OpenRC řeší socketovou aktivaci, jak řeší logování standardního výstupu, jak řeší zpětné informování od služby, že nastartovala a poskytuje své služby? Jak zajistíte s OpenRC to, aby webserver měl spojení k databázi, když ho potřebuje? Hluboce se zamyslíte, řeknete, že do dvou minut by mohla databáze nastartovat, a přidáte na začátek startu webového serveru dvouminutové čekání?

Každý z nich je schopný nahradiť klasický init
Jenže většina uživatelů nechce nahrazovat klasický init něčím, co se bude chovat úplně stejně. Chtějí správce služeb, který bude službám poskytovat podporu v tom, co služby obvykle potřebují (aby si to každý nemusel implementovat znova sám, jako se to děje se SysVinitem) a který dokáže zajistit spolupráci služeb. To, že takový správce služeb, aby mohl rozumně fungovat, bude mít jako jednu ze svých komponent i PID 1, je jenom jedna taková nepodstatná maličkost.

> Aha, tak vy jenom nevíte, co je to proces.

Nie, ja na rozdiel od Vas len tusim o com hovorim. Mal som to potesenie kod SystemD skumat pri svojom pokuse reimplementovat parser na unit files. Je mimochodom dostupny na githube, proces o ktorom hovorime najdete v "main.c" :)

> A jak by ten server potom nastartoval nějaký libovolný správce služeb?

Serveru by malo byt jedno, ci je pusteny z bashu, initu alebo cez spravcu sluzieb. A pokial mi je zname, vacsina serverov takto funguje. Pristup apache a spol nieje pravidlom, ide o vynimku danu asi hlavne tym, ze sa snazi fungovat na obrovskom mnozstve systemov.

SystemD ale takyto princip neuznava, respektive ho poklada za "legacy". Spravna Linuxova sluzba by po novom mala predpokladat spustenie pod spravcom, ktory jej preda konfiguraciu, sockety, pipy, nastavi limity, komunikuje s nou cez dbus a zabezpeci zotavenie... Spravca samozreje moze byt lubovolny, za predpokladu, ze je to SystemD :)

Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.

> (...) žebřiňákem a ne autem jsme začli proto, že je to jednodušší (...)

Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.

> To, že takový správce služeb, aby mohl rozumně fungovat, bude mít jako jednu ze svých komponent i PID 1, je jenom jedna taková nepodstatná maličkost.

Podstatnost tejto malickosti uz bola demonstrovana tak silne, ze do SystemD pridali kod restarujuci system pri pade :) Ono totiz na nic z toho, co ste menoval PID 1 nepotrebujete, ale ked uz Vas posadne komplex a rozhodnete sa ho predsalen obsadit, zistite, ze kazdy pad toho bazmeku zrazu znamena kernel panic.

> Jak OpenRC řeší (...)

Inetd, start-stop-daemon -1, start-stop-daemon, symlinkom vo /var/run/open­rc/started/, nastavim "needs mysql". V poradi ako ste sa pytal.

Ale skratene, rovnako ako vsetky ostatne inity napisane po 1995. Fakt by sme nemali prepadat iluzii, ze SystemD prisiel s niecim novym :D

proces o ktorom hovorime najdete v "main.c"
Ne, proces opravdu nenajdete v souboru main.c. Proces je spuštěný kód v paměti počítače, který má nějaký identifikátor přiřazený jádrem.

Serveru by malo byt jedno, ci je pusteny z bashu, initu alebo cez spravcu sluzieb.
Souhlasím.

A pokial mi je zname, vacsina serverov takto funguje.
To je vám známo špatně. Spousta serverů má speciální mód pro hloupé správce služeb, kdy se server sám daemonizuje, aby se dostal z dosahu správce služeb.

SystemD ale takyto princip neuznava, respektive ho poklada za "legacy". Spravna Linuxova sluzba by po novom mala predpokladat spustenie pod spravcom, ktory jej preda konfiguraciu, sockety, pipy, nastavi limity, komunikuje s nou cez dbus a zabezpeci zotavenie...
Nesmysl. Servery, které se prostě spustí na popředí, provádějí svou činnost a zapisují na standardní výstup, servery, které prostě spustíte z shellu a chovají se úplně stejně, jako když je spustíte ze správce služeb, fungují se systemd perfektně. Mnohem lépe než se SysVinitem.

Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.
Ani náhodou. Služba ve Windows má speciální vstupní bod, jiný, než když aplikaci spustíte ručně. Další speciální funkci má pro ukončení služby. Nic takového systemd nevyžaduje. Když si vytvoříte „server“ tím, že spustíte netcat aby naslouchal na nějakém portu a zrcadlil přijatá data třeba na standardní výstup, můžete ten spouštěcí příkaz zkopírovat do unit souboru a poběží vám to jako služba pod systemd, včetně správného ukončení.

Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.
Přečtěte si ještě jednou, co jsem doopravdy napsal.

Auta byla lepší – a aby mohla být lepší, nedalo se toho dosáhnout jinak, než že byla komplikovanější než žebřiňák. Stejně tak je Linux komplikovanější než DOS, aby mohl být lepší, btrfs je komplikovanější než ext3 nebo FAT, aby mohl být lepší než tyto souborové systémy. To, že dokážeme udělat něco lepšího, je v drtivé většině případů dané tím, že zvládneme komplikovanější věc, na kterou bychom dříve neměli.

Ono totiz na nic z toho, co ste menoval PID 1 nepotrebujete, ale ked uz Vas posadne komplex a rozhodnete sa ho predsalen obsadit, zistite, ze kazdy pad toho bazmeku zrazu znamena kernel panic.
Ale pořád na PID 1 potřebujete proces, který spustí správce služeb a který bude řešit zombie procesy. No a co teď s tím dělat, když takovou aplikaci nemáte – SysVinit toho dělá zbytečně moc, ale spolupracovat rozumně se správcem služeb neumí. Tak asi nezbývá, než ten kód pro PID 1 napsat.

nastavim "needs mysql"
Jak se OpenRC dozví, že MySQL je schopna obsluhovat požadavky? Ten aplikační server totiž nepotřebuje, aby začal start procesu MySQL, ale aby databáze byla schopná přijímat požadavky. A pokud byste k takové signalizaci chtěl použít to, že se spuštěný proces ukončí – jak potom zjistíte, že se ukončil ten skutečně výkonný proces?

Ale skratene, rovnako ako vsetky ostatne inity napisane po 1995.
Ano, sleep s bulharskou konstantou ve startovacích skriptech. To je skutečně profi řešení.

> Ne, proces opravdu nenajdete v souboru main.c. Proces je spuštěný kód v paměti počítače, který má nějaký identifikátor přiřazený jádrem.

Nie, proces je systematicka seria operacii smerujuca k urcitemu cielu :)

> Spousta serverů má speciální mód pro hloupé správce služeb, kdy se server sám daemonizuje, aby se dostal z dosahu správce služeb.

Povedal by som, ze si zamienate init so spravcom sluzieb. Systemy, ktore pouzivaju to druhe vacsinou pustaju servery s flagmi, ktore demonizaciu vypinaju.

> a aby mohla být lepší, nedalo se toho dosáhnout jinak, než že byla komplikovanější než žebřiňák.

To je skutocne zaujimava teoria. Suhlasil by ste s nazorom, ze je elektromobil z mnohych pohladov lepsi, nez klasicke auto?

Pretoze technicky su elektromobily 2 magnety s baterkou, riesenie ovela, ovela, OVELA jednoduchsie nez riadena explozia chemicky upravovanej zmesi plynov v presne tvarovanych piestoch klasickeho motora.

> Jak se OpenRC dozví, že MySQL je schopna obsluhovat požadavky? Ten aplikační server totiž nepotřebuje, aby začal start procesu MySQL

Pocka na vytvorenie socketu. Pomerne jednoduche.

> Ano, sleep s bulharskou konstantou ve startovacích skriptech. To je skutečně profi řešení.

Bulharske konstanty su najdolezitejsim stavebnym prvkom kazdeho systemu :) Ale inotify funguje tiez vcelku dobre.

Nie, proces je systematicka seria operacii smerujuca k urcitemu cielu :)
Bavíme se tu o linuxových procesech…

Povedal by som, ze si zamienate init so spravcom sluzieb.
Já bych řekl, že nevíte, co je to init. Ani v linuxových instalacích, kde se používal nebo používá SysVinit, nespouští služby init, ale až nějaká nadstavba (obvykle shellových skriptů), která je z toho initu spuštěná. Takže i tyhle instalace mají nějaký správce služeb, i když je co do funkčnosti velmi primitivní a často nemá ani jméno.

To je skutocne zaujimava teoria. Suhlasil by ste s nazorom, ze je elektromobil z mnohych pohladov lepsi, nez klasicke auto?
Elektrický motor je podstatně jednodušší, než spalovací motor. Proto také po žebřiňáku nenásledovala auta se spalovacím motorem, ale nejprve elektromobily. Ke zvládnutí komplikovanosti spalovacích motorů bylo potřeba se nejprve dostat. Pak se podařilo zvládnout i tuto komplikovanost a rozšířily se automobily se spalovacími motory, protože byly lepší, než tehdejší elektromobily, u kterých byl problém s dojezdovou vzdáleností. Dnes už zase zvládáme komplikovanější věci (efektivnější baterie, rychlejší dobíjení, efektivnější asynchronní motory), takže nám to umožňuje dělat elektromobily, které jsou v mnohém lepší, než automobily se spalovacími motory. Je to pořád tak, jak jsem napsal na začátku – nejprve musíme zvládnout komplikovanější technologii, a pak díky té komplikovanější technologii můžeme něco zlepšit.

Pocka na vytvorenie socketu. Pomerne jednoduche.
To je fajn. V době, kdy jsem OpenRC nepoužíval, to nic takového neumělo. Pořád je to ale předpokládám jen pozorování nějakých vedlejších efektů (ukončení procesu, vytvoření souboru). Nebo už OpenRC umí i to, že mu proces v okamžiku plné inicializace pošle nějakou zprávu?

Ale inotify funguje tiez vcelku dobre.
I na inet sockety?

> Na druhou stranu je to prijemne zlepseni, ze pokud tohle vse nechci po 151. resit v serveru, co pisu, tak ze nemusim - muzu pouzit funkcionalitu spravce sluzeb a spoustu dalsich veci z nej.

Lenze ty to samozrejme riesit musis, nakolko SystemD funguje len na par specifickych konfiguraciach Linuxu. Takze poriesis jeho i vsetkych 15 konkurencnych standardov a potichu budes dufat, ze ten 16-ty uz bude dostatocne pouzitelny na to, aby sa uchytil.

> A? Normalni soucast zakladniho core systemu skoro vsude.

Vlastne si takuto hovadinu pred SystemD dovolil spravit iba Windows :)

> Hezky priklad. A systemd vytlacil ostatni init systemy rychlosti, komplexnim resenim beznych situaci a jednoduchosti pro autory distribuci a uzivatele.

... rovnako ako v 90-tych rokoch vytlacil Unixy technicky vyspelejsi OS od Microsoftu. To bol sarkazmus, mimochodom.

> Je proste holt potreba se smirit s tim (...)

Vlastne som doposial realne nasadenie SystemD u nikoho vacsieho nevidel. Pisu sa sice kvanta clankov o tom, ako je stvoreny pre kontainery, AWS, embeded zariadenia, LHC... ale vsetko je to len krasna teoria, od ktorej sa realne nasadenie drzi setsakramentsky daleko. Nechapem preco...

Podotýkám že to nejsou jen Windows, kde je správa služeb řešená rozumně. Solaris má Service Management Facility, který používá deklarativní definici servisu, závislosti a API pro správu. Apple má launchd, který má ty podobné vlastnosti. Pro mě je velmi těžké pochopit, jak někdo může považovat za výhodu klubko skriptů, ke kterému ani neexistuje API. Argument "dělá se to tak od roku 1979, takže to musí být správně" nějak neberu. Spíš to vidím tak, že "klasiku" obhajují admini, které dost často pohled uživatele nebo vývojáře jaksi nezajímá; hlavně aby se to neměnilo a nemuseli se učit nějaké novinky.

Ale on nepsal nic o systemd. Jen obhajoval tenhle styl správy služeb nezávisle na implementaci oproti původním init skriptům.

Jak nepopisuje? Už jenom tady v diskuzi několik lidí píše jaké s tím měli problémy.
Opravdu? Mohl byste uvést konkrétní komentáře v této diskusi, kde někdo popisuje problém způsobený systemd, který dotyčný sám řešil?

A já osobně si pamatuji, že často lidi popisují, že jim po restartu nestarují služby a to se stalo i mě
Fajn. A teď ještě zbývá napsat, proč si myslíte, že je to chyba systemd. Mně se mnohokrát stalo, že mi nenastartovala služba na systému se SysVInitem – ale neobviňoval jsem z toho SysVInit, protože chyba byla jinde. Stejně se mi to stalo i se systemd, ale také to nebyla chyba systemd. Rozdíl je v tom, že se systemd pro mne bylo snazší zjistit příčinu a jednoduše to opravit tak, aby k tomu příště nedocházelo.

o systemd se nepochybuje, je skvělý, je přínosný a tak musíme mlčet
To je akorát vaše podsouvání, to nikdo nikdy netvrdil.

Ostatně když už si nastavíš unit file, spustíš, jede to a po restartu nenaběhne a nejde spustit, tak bych o nějakém vylepšení initu rozhodně nemluvil.
Pořád nepíšete nic, co by ukazovalo na chybu v systemd. Tohle se vám může stát s jakýmkoli init systémem, přičemž u SysVInitu je to mnohem pravděpodobnější, protože tam si službu klidně můžete spustit ručně přímo pomocí startovacího skriptu, a pak běží v jiném prostředí, než když jí spustíte přes init.

A už to zas začíná, Jirsákovo otravné kolečko
Milý NULLe, tomu se neříká „Jirsákovo otravné kolečko“, říká se tomu diskuse. Chápu, že pro vás je otravné, když po vás někdo chce, abyste svá tvrzení dokládal – když vy si je jednoduše vymýšlíte, takže nic doložit nemůžete. Ale tak to holt v diskusi chodí – když vy si vymyslíte, že v této diskusi někdo psal o problémech způsobených systemd, můžete čekat, že někdo bude chtít vědět, které to byly komentáře. V tom není nic zákeřného proti vám, prostě jsem jenom chtěl vidět příklad toho, že někdo používá systemd a má s ním problémy.

Dokonce se o tom píše hned v prvním příspěvku u toho vlákna ve kterém toto píšeš.
Opravdu? A kde? Já tam vidím popsaný akorát problém s restartem serveru a následným nenaběhnutím některých služeb – ale nikde tam nevidím nic, podle čeho by se dalo usoudit, že je to chyba systemd. Jak už jsem psal, já jsem podobných chyb zažil spoustu se SysVinitem, s daemontools i se systemd, a nikdy to nebyla chyba init systému, vždy to byla moje chyba, protože jsem něco špatně nakonfiguroval.

Závěr: systemctl s tím rozhodně nemá co dělat, přestože službu lze manálně nastartovat, běží, funguje a dříve přes systemctl běžela a občas běží. Řešení je zřejmé: jsem lhář nebo hlupák, systemd je v pořádku.
Správně je varianta b, jste hlupák a ani jste si nepřečetl dokumentaci k systemd. Poradím vám – unit soubor musí mít nakonfigurováno, že se služba má spouštět v nějakém cíli (obdoba SysVinit levelů), a pak se musí služba povolit – příkazem systemctl enable.

ok, může se to dít i s initem ale kde je pak ta super výhoda proti initu?
Pokud jste si myslel, že systemd má křišťálovou kouli a pozná, co byste chtěl, aby udělal, pak jste se mýlil. Ne, systemd křišťálovou kouli nemá – když chcete, aby se nějaká služba spustila po startu systému, musíte to systemd říct. Ano, v tomhle je systemd úplně stejně hloupé, jako SysVinit – dělá přesně to, co mu administrátor řekne, že dělat má. Akorát těch možností, co a jak má dělat, má systemd oproti SysVinitu kapánek víc.

Ano je.Pozice, do které se mě snažíš opět uvrtat, tedy že cokoliv řeknu je automaticky lež dokud neprokážu opak tak taková diskuze je nechutná.
To ale špatně chápete. Já netvrdím, že cokoli řeknete, je automaticky lež. Vyvracím věci, o kterých si myslím, že jsou jinak, než jste napsal. A pokud tvrdíte, že někde něco je, a já to tam nevidím, ptám se, kde konkrétně to je. Nevím, jak jinak bych vám měl vyvracet neexistenci něčeho – měl bych ocitovat všechny komentáře v této diskusi a na závěr napsat, že to, co tvrdíte, v žádném z nich napsané není? K čemu by to bylo – přečíst si je snad můžete i bez toho, abych je všechny citoval. Pokud si myslíte, že to v nějakém komentáři je napsané, nemělo by být nic snazšího, než ten komentář odkázat, a pak se můžeme bavit konkrétně o něm.

Za chvilku po mě budeš chtít všechno notářsky ověřovat.
Argumentační klam – šikmá plocha.

Ovšem od člověka, který každý svůj výrok považuje za fakt
Argumentační klam – podsunutý argument.

povolil podle toho návodu
Kde to bylo napsané v tom vašem popisu?

tak se občas po restartu pustila
Kde to bylo napsané v tom vašem popisu?

A i kdybych to nepovolil, to že občas jde manuálně přes systemctl spustit a občas ne, občas jde vypnout a občas ne, to je zřejmě taky v pořádku.
Argumentační klam – podsunutý argument. Pořád jste nevysvětlil, jak jste přišel na to, že je to chyba systemd. Jako daleko pravděpodobnější se jeví, že to byl chybně napsaný unit soubor. Už jsem viděl mnoho případů, kdy se služba nechovala správně, u sebe i v diskusích, pod různými init systémy – a nikdy to nebyla chyba init systému, vždy to byla chyba konfigurace. Pokud chcete, aby vám někdo věřil, že to byla chyba systemd a ne vaše, asi byste měl napsat trochu víc o tom, jak se ta chyba projevovala. Pokud jste to zkoumal a zjistil jste, že je chyba v systemd, musel jste přece zjistit mnohem víc informací – co bylo vypsáno v logu, jestli systemd proces vůbec nenastartoval, nebo ho nastartoval ale s chybnou konfigurací a proces se následně ukončil, nebo jestli ho systemd nastartoval ale později proces zabil…

Ale netvrdím, neviděl jsem v životě a sám jsem ani nikdy nevyprodukoval kód, kdeby nebyla nějaká chyba.
Což ale neznamená, že je potřeba každou chybu administrátora svádět na systemd a na základě toho tvrdit, že systemd nefunguje. Já si myslím, že systemd má dost skutečných chyb, a nechápu, proč se na něj někdo snáží naházet i chyby, které chybami systemd nejsou.

Nechápu ale proč vždycky přileze nějaký nazdárek, momentálně ty, a začne mi tvrdit, že se to neděje.
Argumentační klam – podsunutý argument. Netvrdil jsem, že se to neděje – pouze mám pochybnosti o vaší interpretaci toho, co se děje. Když mám zkušenost, že problém bývá obvykle jinde, než jak ten konkrétní případ popisujete vy, a vy své tvrzení nijak nedoložíte – nedivte se, že pak vašemu tvrzení nevěřím. Zvlášť když mám s vámi takovou zkušenost, že vždy něco tvrdíte, ale když to máte něčím doložit, začnete se vykrucovat, že vy přece nic dokládat nemusíte.

Mě by stačilo kdyby dělal to co je v unit file.
Podle mých zkušeností to dělá. Ještě jsem neslyšel věrohodně o případu, kdy by to bylo jinak – sice to občas někdo tvrdí, ale pak se ukáže, že to je jen jeho ničím nepodložená domněnka, protože ani nezjišťoval, kde je vlastně problém.

Přišel jsem na to tak, jak jsem ti už psal na začátku "Jirsákova kolečka". Občas to startuje, občas to přes systemctl jede, občas ne. Manuálně to jede pořád. Pardon jelo, už to dávno nepotřebuji. V logu nebylo nic. Co je na tom nepochopitelného?
Nepochopitelné na tom je, proč si myslíte, že za to může systemd. Jak už jsem psal, viděl jsem už mnoho případů, kdy byl takovýhle problém s nějakou službou, a bylo to pod SysVinitem, daemontools, OpenRC i systemd. A chyba nikdy nebyla ve správci služeb ale vždy v konfiguraci konkrétní služby.

Když údajně nedoložím že to tak je, jak teda můžeš vědět, že to tak není?
Zkušenost. Vy jste nenapsal jediný důvod, proč by to měla být chyba systemd – a ve všech případech, se kterými jsem se setkal, to byla chyba konfigurace služby, nikoli chyba init systému.

Dokaž mi že lžu když to tvrdíš.
Kde jsem tvrdil, že lžete? Akorát jsem se slušně zeptal, jaké máte důvody pro to, abyste tvrdil to, co tvrdíte. Já nemůžu za to, že vás hrozně uráží, když se vás někdo zeptá na to, jak jste ke svým ničím nepodloženým tvrzením dospěl. Nemůžu za to, že si myslíte, že jediný, kdo může zpochybňovat vaše tvrzení, je nějaké veličenstvo.

@NULL Problém není ve vaší zkušenosti, ale v tom, že z ní dovozujete něco, co z ní v žádném případě neplyne. A opět už jste na to byl několikrát upozorněn. Takže by se slušilo napsat: „OK, měl jsem problém se startem služby na systému, kde se používalo systemd. Neřešil jsem příčinu, vyřešil jsem to (možná) instalací jiného správce služeb, kde jsem se se stejnou chybou nesetkal – takže nevím, v čem byla chyba, mohla být v systemd, mohla být ve službě samotné, ale nejspíš byla v konfiguraci služby.“

Variantu, že je to chyba vaší konfigurace, jste zvažoval?

Takže vám to fungovalo, jak má, ale vy si přesto stěžujete a tvrdíte, že je to chyba systemd. Aha.

Ono ti to mozna nefungovalo poradne nikdy - udelal jsi nejakou chybu, kvuli ktere je chovani nahodne. A pak sis na zaklade par pozorovani udelal nejakou nerealistickou predstavu.

Kazdopadne pokud tu nechces jenom placat dokola, tak posli tu unitu, co jsi napsal, na gist a placni sem link. Nejspis si tve chyby rychle nekdo vsimne.

Od začátku ti píšu, že to fungovalo jak má až na občasné výpadky.
A já vám od začátku píšu, že tohle je obvyklý projev chybné konfigurace – třeba chybných závislostí.

Popíšu vám znova podrobně takový příklad chybné konfigurace. Představte si nějakou webovou aplikaci, která používá databázi – třeba e-shop. Bude to aplikace, která běží na nějakém aplikačním serveru, který spravuje pool připojení do databáze. A protože ta aplikace bez spojení s databází nemůže nic dělat, při startu aplikace se ověří spojení s databází, a pokud se ho nepodaří navázat, aplikační server se ukončí. No, a protože ta aplikace zase není nijak rozsáhlá, databázový server běží na stejném serveru, jako ta aplikace.

Jako správce služeb máte na daném stroji systemd, který služby startuje paralelně. A autor unit souboru zapomene na to, že webová aplikace závisí na databázi. Restartuje se systém, databáze se náhodou stihne nastartovat dřív, než webová aplikace dospěje k testu spojení, a všechno funguje. Pak se znova restartuje systém, databázový server už to nestihne a webová aplikace se po neúspěšném pokusu o připojení k databázi ukončí. Podobně když to testujete ručně – databázový server vám běží, nastartuje i webová aplikace. Pak něco testujete, vypnete databázi, zkusíte nastartovat webový server – a hle, webový server se krátce po startu záhadně ukončí. NULL má jasno, ke změně došlo v systemd, protože ke změně dochází vždy v systemd, jak dokazuje tento příklad.

My ostatní víme, že problém byl v konfiguraci, chybělo uvedení závislosti webového serveru na databázi. Řešení po startu by bylo prostě uvést do unit souboru natvrdo závislost a systemd by počkal, než nastartuje databáze,a teprve pak by startoval webový server. Novější řešení (pokud to databáze podporuje) je aktivace pomocí socketů, kdy webový server bude záviset na socketu databáze, může se startovat paralelně s databází, při pokusu o navázání spojení se ve skutečnosti spojí s „proxy“ systemd a ta pak předá spojení databázi, až bude databáze schopná požadavky vyřizovat. Z pohledu webového serveru to pak nebude vypadat, že je databáze nedostupná, jenom bude odpověď na první spojení trvat o něco déle. Takže i tam by mohlo dojít k „záhadnému“ nenastartování, záleží pak na tom, jak se v té webové aplikaci nastaví timeouty pro spojení s databází.

Byla to výše uvedené chyba v konfiguraci? Chovalo se to přesně tak, jak popisujete? Bylo řešením opravit konfiguraci?

Takže mám měnit konfiguraci aby to nefungovalo jak má a občas fungovalo?
Ne, bylo by vhodné konfiguraci upravit tak, aby to fungovalo vždy. K tomu je ovšem potřeba té konfiguraci rozumět, ne to svádět bez důkazů na systemd, „protože za to vždy může systemd, jak ukazuje například tento případ“.

Každopádně to vypadá že jsme se posunuli do další fáze Jirsákova kolečka, tedy výběru nové věty, jejího vytržení z kontextu celé debaty a pruzení s dalším "jako nepochopením".
Ale kdepak. Posunuli jsme se jenom k tomu, že vaše podezřelé ničím nepodložené tvrzení obhajujete evidentním nesmyslem. A tváříte se, že vaše dedukce je správná, protože samozřejmě, když vaše konfigurace fungovala jednou, je to důkaz, že je bezchybná a musí fungovat vždycky. Tak vězte, že to tak není, uváděl jsem i protipříklady, další jsem vám podrobně popsal na začátku tohohle komentáře. Tak třeba to konečně pochopíte.

Protože to nejprve jelo a pak už nejelo a pak zase jelo. Jak kdy. Na službě samotné jsem nic něměnil. nic neaktualizoval . . . .
Mohl byste alespoň naznačit, co vás vede k tomu myslet si, že tohle odůvodňuje, že je příčina na straně systemd? I pokud by to byla chyba na straně software, podle čeho soudíte, že je to chyba systemd a ne té služby? A jinak přesně takhle se projevují chyby konfigurace – start té služby závisí na něčem, co nemáte v konfiguraci ošetřené, a pak se start povede nebo nepovede podle toho, zda ta podmínka náhodou je nebo není splněná. Typicky je to závislost na jiné službě – když ta jiná služba náhodou je nastartovaná (nebo se při startu systému náhodou stihne nastartovat dřív), vaše služba naběhne, pokud nastartovaná není, start vaší služby selže.

Ale ty jsi nenapsal jediný proč by nemohlo.
Já jsem taky nikdy nenapsal, že by nemohlo. Nejdřív jsem se ptal, proč si myslíte, že zato může systemd – tak nějak jsem předpokládal, že když to tvrdíte, že k tomu tvrzení máte aspoň nějaký důvod.

A k tomu, zda by to mohla nebo nemohla být chyba init systému – mohla, ale z mé zkušenosti je to velmi nepravděpodobné. Moje zkušenost je taková, že se zatím vždy ukázalo, že je to chyba konfigurace. Nemám důvod měnit názor na základě vašeho tvrzení, že sice nemáte žádný důkaz a ani jste to nezkoumal, zda to byla chyba systemd, ale prostě vás napadlo, že by to chyba systemd mohla být, tak jste to prohlásil za chybu systemd.

Nicméně jsem to zkoušel dohledat, ale po činu jsem to důkladně "vyčistil". Takže bohužel.
Bohužel pro vás. Akorát se ukazuje, že jste neměl v ruce jediný náznak toho, že by za to mohlo systemd – prostě jste se jen tak rozhodl, že za viníka označíte systemd. A pak to v diskusi vydáváte za fakt, a kdybych se vás nezeptal na důkazy, ani bychom se nedozvěděli, že to není ani fakt, dokonce ani jen podezření, ale je to vaše rozhodnutí. A pak se mi divíte, že po vás chci, abyste svá tvrzení dokládal…

Několikrát jsem ti napsal proč si myslím že je to způsobeno systemd, bez výsledku.
V tom, co jste vy napsal, ale není ani náznak toho, že by za to mohl systemd. Popsal jste běžnou situaci, ke které typicky dochází při špatné konfiguraci služby. A také by teoreticky někdy mohla být způsobena chybou služby nebo chybou správce služeb. Vy jste neuvedl žádný důvod, proč jste se rozhodl, že by to měla být zrovna chyba systemd.

Ty jsi uvedl jenom zkušenost, ovšem v tvém případě je to samozřejmě dostatečné, v mém je zkušenost samozřejmě nedostatečná. Proto to veličenstvno.
Zase mi něco podsouváte. Vámi popsaná zkušenost není dostatečná nikoli z toho důvodu, že je vaše, ale proto, že z toho, co jste popsal, v žádném případě neplyne vámi uváděný závěr. Já jsem popsal zkušenosti, kdy se to chovalo přesně tak, jak popisujete vy – služba někdy startovala a někdy ne. Následně jsem to řešil, ladil, četl dokumentaci, až jsem dospěl k tomu, že je chyba v konfiguraci, pochopil jsem, proč je to chyba a chybu jsem opravil – a pak se to začalo chovat správně. (Typicky byl problém v závislostech – že ona služba ke svému startu potřebovala něco, co při startu náhodně mohlo a nemuselo být dostupné.) Myslím, že to jsou dostatečné důvody myslet si, že chyba byla v konfiguraci. Naproti tomu vy jste nic nezkoumal, prostě jste si jenom hodil kostkou a vyšlo vám, že za to může systemd.

Nevím proč by to mělo být službou, když jela OK pokaždé ať už ručně nebo přes systemctl (pokud to přes systemctl zdařilo).
Stejně tak nevím, proč by to mělo být systemd, když to fungovalo pro všechny ostatní služby.

Navíc jak už jsem mnohokrát psal, za nejpravděpodobnější považuju chybu konfigurace.

Jediný článek řetězu který je v tom proměný je systemctl.
Co je na systemctl proměnného? Vy jste mezi tím měnil verzi systemd?

Buď jsi schopný tento odstaveček pochopit > co mě vede k tomu že je to systemd chybka a nebo ne
Já to chápu – prostě jste náhodně vylosoval systemd a svádíte to na něj, přitom jste se ani nepokusil zjistit, v čem by mohl být problém.

Postavil jsi mě, jak ty to umíš, do nějaké pozice že systemd je špatný protože měl bug. To ale netvrdím, jenom jsem napsal že mám tuto zkušenost.
Ne, vy sám jste se postavil do pozice, že máte nějakou zkušenost, a místo abyste napsal, co mohlo být příčinou, náhodně jste si vylosoval systemd a označil jste za příčinu chybu v něm. Přitom je daleko pravděpodobnější, že to byla vaše vlastní chyba v konfiguraci.

nebo prostě občas napíšu co si myslím bez toho, abych ti musel dokládat nějaký elaborát a čekat, jestli mi to milostivě uznáš.
Nic mi dokládat nemusíte ani nemusíte čekat, jestli vám to milostivě uznám. Ale vy se zase smiřte s tím, že když budete vaše ničím nepodložené výmysly vydávat za fakta, já se budu ptát na důkazy – a když je nebudete schopen napsat, tak o těch vašich tvrzeních budu psát, že jsou to podle mne ničím nepodložené výmysly.

Ne, proměný tak, že jednou něco spustí, pak zase ne.
Jak jste přišel na to, že se takhle systemd chová? Připomínám, že jste tuhle „znalost“ použil při interpretaci té vaší zkušenosti, takže tu „znalost“ jste musel mít už před tou zkušeností.

Pak se div že lidi reagují jak reagují. Aspoň si laskavě přečti co ti někdo píše
Já čtu, co píšete. Nereagují lidi, reagujete vy – strašně se vám nelíbí, když poukážu na do nebe bijící nelogičnost, kterou v textu máte.

A speciálně pro tebe: proměný - jeho chování se měnilo.
Což je pouze vaše ničím nepodložená domněnka. Stejně tak se mohlo měnit chování služby, nebo (což je nejpravděpodob­nější) se mohlo měnit okolní prostředí (třeba stav jiných služeb).

Představte si, že máte službu, na začátku které bude if (rand() > 0.5)) exit(0); Jak se to bude chovat? Přesně tak, jak popisujete – zhruba v polovině případů se služba normálně nastartuje, v polovině případů se nastartuje a hned ukončí. Souvisí ten problém nějak se systemd? Ne, vůbec. Ale vy o tom budete tvrdošíjně tvrdit „chování systemd se měnilo“.

Vy totiž stále nechápete, k čemu vlastně došlo. Vy jste si myslel, že jste dal systemd pokyn, že má spustit nějakou službu. A služba nakonec neběžela. To je všechno, co o té věci (snad) víme. Problém mohl být v tom, že jste systemd ten pokyn ve skutečnosti nedal. Byla by to změna chování systemd? Nebyla. Problém mohl být v tom, že systemd tu službu nespustil. Byla by to změna chování systemd? Ano, v tomto případě ano. Dále je možné, že se ta služba spustila, ale vzápětí se sama ukončila. Byla by to změna chování systemd? Ne, opět nebyla. A pak je také možné, že se služba sice spustila a běžela by dál, ale něco ji ukončilo – což opět mohla být změna chování systemd (pokud by ji ukončilo svévolně), nebo to změna chování systemd být nemusela (pokud to službu ukončilo na základě vaší konfigurace, nebo pokud službu ukončilo něco jiného).

Výše uvedený odstavec popisuje možnosti, které nastaly, na základě toho, co jste popsal. A vy pořád tvrdíte, že z těch možností nastala druhá nebo čtvrtá, přitom jste neuvedl nic, co by tomu nasvědčovalo – a tipuju si, že nebudete schopen ani vybrat mezi tou druhou a čtvrtou možností.

Tak mi dokaž že to zapříčiněno systemd nebylo
Já nevím, jestli to to bylo nebo nebylo zapříčiněno systemd. Vím jenom to, že vy to vůbec nedokážete posoudit, takže nemáme vůbec žádné informace o tom, co mohlo být příčinou. Takže pak zbývá jenom spolehnout se na statistiku, podle které je velice nepravděpodobné, že by příčinou bylo systemd. A to je to, co tvrdím od začátku.

jelikož nemáš přístup k mému systému, tak to nemůžeš vědět, tedy čistě vaříš z vody
Vidíte. A vy přístup k vašemu systému máte (i když, možná zase jenom něco špatně interpretujete…), takže byste to vědět mohl, a taky jenom čistě vaříte z vody.

A nebo, prostě budeš respektovat co píšu
Vzhledem k tomu, že často píšete nesmysly, které pak nejste schopen nijak dokázat, budu i nadále vaše tvrzení, která vypadají velmi podezřele a která nedokážete, považovat za nesmysly.

začne něco tvrdit o něčem, u čeho nebyl, nemá z toho záznam a krom systemd (ani neví jaká verze) ani neví o jakou službu šlo (ani neví jaká verze).
Já fakt nemůžu za to, že jsou vaše tvrzení tak očividně nesmyslná, že k jejich vyvrácení ani není potřeba znát takovéhle detaily.

Což ale absolutně nezabrání nazdárkovi tvrdit že je vše jinak a on ví nejlíp co se dělo.
Netvrdím, že vím nejlíp, co se dělo. To, že je vše jinak, to je pravda – nemůžu za to, že píšete tak průhledné nesmysly, ze kterých je na první pohled vidět, že vůbec netušíte, o co jde a jen si vymýšlíte.

Ano, co popisuji se mi stalo, v logu bylo prd.
Problém je, že vy popisujete, co se vám stalo, jenže ve skutečnosti je to směs (možná) faktů a ničím nepodložených domněnek. A teprve když mi to připadá podezřelé a zeptám se, vyleze z vás, že to je vlastně jenom domněnka (přičemž vy si nadále myslíte, že je to fakt, protože tomu vůbec nerozumíte).

pořád tvrdíš že to nechápeš
Ano, nechápal jsem, odkud se bere vaše přesvědčení, že to byla chyba systemd. Už jsem to pochopil – prostě jste si to vymyslel.

klidně učiníš závěr a ještě mi ho předhazuješ jako pevný jak nějaký výsledek výzkumu
Závěr jsem učinil jenom z vašich tvrzení – že nejste schopen posoudit, v čem mohl být problém, takže vašim tvrzením o tom, co bylo příčinou, není možné přikládat žádnou váhu.

To je matematický model chování systemd?
Ne, to byl příklad kódu na začátku nějaké služby. V mém komentáři to bylo napsáno. Jak chcete o něčem diskutovat nebo něco konfigurovat, když ani neumíte pochopit jednu větu?

A navíc jsem ti psal, že po spuštění ručně se to chovalo normálně
Ano, to je pro chybnou konfiguraci závislostí typické – než se dostanete k tomu nastartovat službu ručně, ta prerekvizita už stihne nastartovat.

ale zase jaksi zafungovala selektivní slepota a nepamatujeme si to
Jistě, a protože si to nepamatuju, proto uvádím příklad, který počítá přesně s tímhle „po spuštění ručně to fungovalo“.

takže buď by všechny ty "exity" vyšly pouze a jenom na běh pod systemd když jsem to zkoušel nebo kontroloval, a nebo by to nemohlo být službou, tedy tímto tvým "příkladem"
Uváděl jsem to jako teoretický jednoduchý příklad, kdy by docházelo k tomu, že služba někdy nastartuje a někdy nenastartuje, a není to přitom chyba správce služeb. Ve skutečné aplikaci asi nic takového nebude, bude to spí závislost na nějakém zdroji.

Tedy se buď potvrzuje co říkám a nebo tu máme službu která jede total random.
A nebo prostě ta služba ke svému běhu potřebuje nějaké zdroje, a vy jste to špatně nakonfiguroval a nezajistil jste, aby ty zdroje měla vždy k dispozici. Což je velice pravděpodobné, protože je to zaprvé statisticky zdaleka nejčastější případ selhání startu služby, a za druhé zjevně vůbec nejste schopen analyzovat příčinu toho problému a místo toho si náhodně vylosujete jednu možnou ale nepravděpodobnou příčinu a tu předkládáte jako fakt.

A nejvíc vás na tom štve, že jste zase napsal nějaký svůj ničím nepodložený nesmysl, a někdo vás zase vyhmátl a upozornil na to. S tím se holt budete muset smířit, že když budete psát do diskusí takovéhle nesmysly, pokaždé se může najít někdo, kdo si to nenechá pro sebe a napíše to otevřeně do diskuse, že píšete nesmysl.

To ale špatně chápete. Já netvrdím, že cokoli řeknete, je automaticky lež.

Nikdo netvrdíte, že to tvrdíte. IMO NULL dává najevo, že se tak v diskuzi CHOVÁTE a za mě s tím souhlas.

Argumentační klam – šikmá plocha.

To je od NULL IMO Hyperbola nikoli argumentační klam.

Argumentační klam – podsunutý argument.

Viz. výše ohledně vašeho chování v diskuzi...

...vlastně celý váš tento příspěvek to ukazuje :). Co řekne Jirsák je automaticky pokládáno za "svaté" co řeknou ostatní považuje Jirsák za kravinu, pokud se to Jirsákovi náhodou nestalo taky :-D

Correlation

Networkmanager = systemd přibližně odkdy?