Hlavní navigace

Debian bez systemd je za dveřmi: Devuan 1.0 RC2

Sdílet

Roman Bořánek 5. 5. 2017

Projekt Devuan se pomalu ale jistě blíží do finiše. Tento fork Debianu, který na rozdíl od něj nepoužívá startovací program systemd, právě vyšel v druhé release candidate verzi 1.0. První verze distribuce původně byla plánována už na rok 2015, ale vývoj nešel podle představ. Toto vydání bude postavené ještě na Debianu 8 Jessie, nikoliv nad nadcházejícím Stretch.

Některé balíčky včetně grafických prostředí jsou na systemd natolik závislé, že se je dosud nepodařilo s initem rozběhat optimálně. Např. GNOME, KDE a Cinnamon nelze nainstalovat během instalace systému. Většinou je lze nainstalovat po instalaci systému, ale víme o tom, že bez systemd mají různé problémy, píšou vývojáři.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 6. 5. 2017 1:16

    __I__ (neregistrovaný) 2001:718:1001:----:----:----:----:----

    príde mi to ako zhovädilosť dávať do prostredí závislosť na konkrétnom init systéme

  • 6. 5. 2017 5:17

    klokan

    Mně naopak připadá jako zhovadilist trvat na tom, že vývojáři aplikací nesmí mít možnost absolutně nic předpokládat, že obecně důležité funkce nesmí být jednou pro vždy součástí prostředí a že každá aplikace musí znovu a znovu vynalézat kolo.

  • 9. 5. 2017 9:42

    SB (neregistrovaný) 78.156.151.---

    Do systemd pochopitelně nevidím, otázkou ale stále zůstává, zda nebyla zvolena nevhodná úroveň abstrakce.

  • 6. 5. 2017 11:01

    NULL (neregistrovaný) ---.freepoint.cz

    @__I__

    1. systemd už dávno není jen init
    2. když je to nové, tak je to přece v pořádk

    "Některé balíčky včetně grafických prostředí jsou na systemd natolik závislé, že se je dosud nepodařilo s initem rozběhat optimálně"

    No, co naplat, výhody "system32" přece něco stojí, že . . . .

  • 6. 5. 2017 11:20

    klokan

    "1. systemd už dávno není jen init"

    Samozřejmě. V tom je jeho smysl.

    "2. když je to nové, tak je to přece v pořádk"

    To netvrdí nikdo. Ale jestli vás to uklidní, tak systemd už dávno není nový.

    "Některé balíčky včetně grafických prostředí jsou na systemd natolik závislé, že se je dosud nepodařilo s initem rozběhat optimálně"

    Dokonce se je nepodařilo rozběhat bez kernelu ani bez CPU, představte si to! To je fakt nehorázné, co si to ten Linus nebo Intel dovolují.

    "No, co naplat, výhody "system32" přece něco stojí, že . . . ."

    Stoprocentně. Mimochodem ta vaše narážka znamená pravý opak toho, co se snažíte tvrdit. Kdyby totiž MS uvažoval tak jako vy, tak by žádný system32 nebyl, dosud by jejich uživatelé byli odkázáni na MS-DOS, o multitaskingu by si mohli leda nechat znát a dny by trávili nekonečným ručním laděním CONFIG.SYS a AUTOEXEC.BAT, to všechno proto, aby se nedotkli citečků těch, kteří si holt zvykli programovat v turbo pascalu a paměť spravovat pomocí EMS a teď jsou bez sebe vzteky, že to nadále už nebude fungovat.

  • 6. 5. 2017 15:16

    NULL (neregistrovaný) ---.freepoint.cz

    Hele, aby bylo jasno hned na začátek, sice jsem ten zlý hloupý NULL, ale ber na vědomí že <noflame>

    1. Ano, ale argumentuje se nutnou náhradou za init - le jaksi se toho nahrazuje víc a víc . . .[tím neobhajuji init]. Kdyby to byla opravdu jenom náhrada za init, tak ani nepípnu. Ono to tak ale jaksi není, že . . . .

    2. No, ve srovnání s initem je nový dost.

    "Dokonce se je nepodařilo rozběhat bez kernelu ani bez CPU, představte si to!"

    Jenomže ono na tom kernelu a CPU jelo roky až do teď, kdy bez systemd (což bych významem s kernelem ani CPU nesrovnával) už prostě nejede. Do srovnání důležitosti CPU+kernel vs. systemd se snad bavit ani nemá cenu.

    "Stoprocentně. Mimochodem ta vaše narážka znamená pravý opak toho, co se snažíte tvrdit. Kdyby totiž MS uvažoval tak jako vy, tak by žádný system32 nebyl, dosud by jejich uživatelé byli odkázáni na MS-DOS,"

    A nebo by přišli s něčím lepším. To že je to nejdednoduší, první nebo nejbližší možnost ještě neznamená že je ta správná. Každopádně nejsem si jist tvrzením které implikuje tvůj výrok, že např. podmínka podpory multitaskingu je vytvořit monolitický blok který "sežere co potká" + alfa rovnou do produkce.

  • 6. 5. 2017 1:51

    Jenda (neregistrovaný) ---.net.upcbroadband.cz

    Co tím získám oproti standardnímu Debianu, když napíšu "apt-get install sysvinit-core"? Myslel jsem, že jde právě o to, aby desktopové balíčky fungovaly bez problému, ale zprávička píše, že se to stejně nedaří. V kombinaci s tím, že Debian Stretch už je prakticky tady a tohle má teprve RC verzi Jessie, mi není jasné, o co se vývojáři snaží.

  • 6. 5. 2017 11:47

    uranix (neregistrovaný) ---.client.rionet.cz

    Pokud nainstalujete zmíněný balíček, tak systemd zůstává, akorát již neběží pod pid1 (systemd-shim). Bez systemd nelze snadno nainstalovat žádné z hlavních grafických rozhraní. Odpovědí na Vaši otázku je tedy to, že Vám úplně bez systemd půjdou (zatím) alespoň některá grafická rozhraní namísto žádného. Dále třeba serverový clamav-daemon má závislost na libsystemd0, což ale až tolik nevadí.

    Dalším využitím Debianu bez systemd je také nepadavý běh na starším (ale stále podporovaném) openvz hostiteli.

  • 6. 5. 2017 5:23

    klokan

    Komunita Devuanu nezahálí. Jakmile vydají verzi 1.0, budou rychle následovat další vylepšení. V nejbližší době se dočkáme ponížení jádra na verzi 1.2.8, odstranění SSH a jeho nahrazení telnetem. V dlouhodobější perspektivě se plánuje přechod celé distribuce na binární formát XCOFF ("a.out") a podpora architektury PDP11.

  • 6. 5. 2017 7:06

    Karel (neregistrovaný) ---.net.upcbroadband.cz

    Proboha proc nekdo dela neco takoveho, to je jako rvat do auta s ridici jednotkou klasicky karburator

  • 6. 5. 2017 7:21

    klokan

    Ničemu nerozumíte. Ford T měl karburátor a tak to musí být. Řídící jednotky, V10, turbo, lehké moderní materiály, hybridní pohon, pohon všech kol a další věci jsou sr*čky pro ty, co nechápou tu pravou Uni^^^žebřiňákovou filozofii.

  • 6. 5. 2017 13:22

    lyon (neregistrovaný) ---.gw2.pvfree.net

    Jestli je něco z motorismu analogií k systemd, tak jsou to kurvítka typu EGR, DPF, S&S, foukáním přetěžovaný downsizing apod., jejichž technický přínos je pro uživatele nulový až záporný. Tady nejde o vývoj, ale o regresi.

  • 6. 5. 2017 13:34

    klokan

    Jasně, stoprocentní regrese. Red Hat vyvíjí systemd a ostatní dista na něj přešla jenom proto, že jsou všichni idioti, masochisti a myslí si, že to je dobrý způsob jak se zbavit uživatelů. Nebo jak jste to myslel?

  • 6. 5. 2017 13:49

    cutile (neregistrovaný) 92.62.225.---

    Bandwagon fallacy ?

    Podle meho skromneho nazoru hral velkou roli i strach, protoze RH financuje nemalou cast vyvoje sw pro Linux vc. (free)desktopu a odmitnuti by znamenalo udrzovat vlastni forky, na ktere jednoduse nemaji zdroje.

  • 6. 5. 2017 15:25

    NULL (neregistrovaný) ---.freepoint.cz

    @cutile

    To nejsi jediný kdo na to naráží (osobně nejsem "insider") a taky se tady už propíralo, že to signifikantní rozhodnutí dister přejít bylo např. u Debianu pouze o jeden hlas, což je sice samozřejmě výhra, ale na vítězný pomník nebo argumentační smeč je to řekl bych málo.

  • 6. 5. 2017 10:44

    Dreit

    Protože někomu vyhovuje ta jednoduchost. Na karburátoru si bohatost směsi doladí kdekdo, ale na vstřikování bez větších investic ani prd.

  • 7. 5. 2017 11:00

    Zopper

    Jenže většina lidí si nechce každý týden špinit ruce a dolaďovat neustále něco v garáži, ale chce, aby to auto bez údržby jezdilo do další servisní prohlídky za rok.

  • 8. 5. 2017 8:11

    Mike (neregistrovaný) ---.antik.sk

    To u mne naopak, za dob initu modleni pred kazdym upgrade aby neco nerozbilo skripty a stejne to bylo rozbity :( nastesti jsou ty doby za nama a od systemd upgraduji vesele a bez potizi.

  • 6. 5. 2017 9:52

    e3k (neregistrovaný) ---.chello.sk

    mne fungoval archonarm pred nejaky casom spolahlivo na openrc. ked som ho instaloval pred nedavnom uz mal systemd a nahodne problemy s prihlasovanim do siete.

  • 6. 5. 2017 12:38

    thedf413 (neregistrovaný) ---.maxtel.cz

    To zní jako skvělá šance, abych se konečně zeptal - co je tak špatného na systemd?
    Používam ten Linux 7 let, začal jsem na Ubuntu, pak pár let Debian a poslední 3 roky Arch. Migrací na systemd jsem tedy asi nějak projít musel. A jediné, čeho jsem si všiml je to, že se jiným příkazem spouští služby a při vypínání systému občas otravuje "a stop job is running for xyz", čehož jsem se zbavil instalací balíku watchdog.

    Co lidi vede k tomu, aby svůj volný čas věnovali zrovna vývoji něčeho tak zbytečného jako Devuan a k tomu tříštili síly, které mohli věnovat rovnou Debianu? Je to něco hlubšího? Nebo je to nějaká náboženská víra stoupenců Stallmana v podobném stylu jako "tohle neni Linux, ale GNU/Linux..." ? Jde o funkčnost, ideologii nebo něco jiného?

  • 6. 5. 2017 13:10

    klokan

    Pro konkrétní odpověď se musíte zeptat některého z nepřátel systemd. Jako jeho příznivce vám můžu nabídnout jenom pohled z druhé strany.

    Záměrně se nezmíním o technických argumentech - ne, že by v určitých případech nebyly nutně oprávněné, ale proto, že nikdo zásadně nikdy nepřichází s nějakou smysluplnou alternativou. Většinou je to jenom o tom, jak "by to šlo" i bez systemd kdyby to existovalo.

    Zakopaný pes je dle mého názoru v tom, že systemd skutečně znamená jistý přerod Linuxu, od v zásadě unixového OS pro adminy, ovládaného primárně pomocí skriptů a konfiguračních souborů, k programátorskému a uživatelskému OS, ovládaného primárně přes abstraktní API. Většině lidí je to jedno, někdo z toho má radost, ale někdo třeba kdysi začal používat Linux specificky proto, že chtěl Un*x a teď má pocit, že "tohle jsme si nedomluvili". Někomu se to prostě nelíbí a cítí nostalgii po éře klasických unixových systému a adminů a někdo to vidí tak, že si do teďka fušoval na svém karburátoru a najednou všichni chtějí jezdit s Teslou a on si s ní neví rady. Jistou roli hraje princip svobodného software, různí lidé ho interpretují různě, ale pro někoho to znamená, že v systému nic nesmí mít závislosti natvrdo. A pak je pár jedinců, kteří to berou skutečně jako jakousi zradu nebo svatokrádež. Nesmíme zapomínat, že stará Unixová komunita nikdy neměla k náboženskému fanatismu daleko: jsou to lidé schopní vidět boj dobra se zlem v tom, jaký kdo používá textový editor ;)

  • 6. 5. 2017 13:17

    hark (neregistrovaný) 141.143.213.---

    Není to úplně fanatizmus, ale dalo by se říci unixová filozofie.
    Akorát to málokdo umí tak pěkně podat, jako Eric Raymond v knize The Art of Unix Programming.
    Přečtení téhle knihy by mělo stačit k vysvětlení, proč je systemd špatně.

  • 6. 5. 2017 13:27

    klokan

    Knihu jsem si přečetl a stačilo mi to k vysvětlení, proč je Eric Razmond úplně vedle.

    Na Unixu a jeho takzvané "filozofii" je mnoho dobrého ale současně taky mnoho katastrofálně špatného. Odmítat se poučit z chyb a trvat na tom, že se se všechno musí dělat tak, jak se to dělalo před čtyřiceti lety z žádného jiného důvodu, než toho, že doteďka se to vždycky dělalo takhle, není zrovna rozumný přístup.

  • 6. 5. 2017 15:38

    Trupik (neregistrovaný) ---.antik.sk

    Lol, "magic potty" ...
    ... To mi pripomína ako som sa snažil vysrať na Bratislavskom letisku a vždy keď som zatlačil a nahol sa dopredu tak automatický splachovač usúdil, že som odišiel a môj holý zadok "ovlažili" striekance od splachovača. Najhoršie sranie za dlhú dobu, 1 z 10, neodporúčam. A podobné to je aj so systemd.

  • 6. 5. 2017 13:38

    cutile (neregistrovaný) 92.62.225.---

    To je sranda jak si protirecis. Na zacatku slibujes jen pohled z "druhe strany", abys pak v zapeti mluvil za stranu "nepratel" (omg).

    Komedie jak obvinujes jine z fanatismu, pricemz sam zjevne postradas jakoukoli sebereflexi. Klasicky priklad projekce …

  • 6. 5. 2017 13:53

    klokan

    Pohled z druhé strany na to, co si myslím, že někomu na systemd vadí. Tak totiž zněla položená otázka, pokud jsi to nečetl. A mimochodem děkuju za názornou ilustraci mé úvodní poznámky o technické stránce : rozumný argument jako obvykle ani jeden, místo toho jdeš rovnou do osobního útoku.

  • 7. 5. 2017 14:00

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Debilove jako ty tu vzdycky potesej, narozdil od zvanilu admini potrebujou aby veci fugovaly a enexistujici logy nebo root prava pro uzivatele to sou veci, bez ktery se s radosti obejdou.

    A s nostalgii to nema nic spolecnyho, systemd proste nefunguje a nidky nebude, protoze z principu nemuze. Duvody sou exaktne stejny jako proc nefungujou widle. Taky nemuzou, protoze je to jeden gigantickej bastl kde spoulu souvisej naprosto ensouvisejici veci ...

    Zarnej priklad, chces ve widlich vypnout logovani? No tak to ti nebude fungovat widlocron. Proc? Protoc ...

  • 6. 5. 2017 13:16

    emsik88 (neregistrovaný) 178.18.75.---

    presne si si odpovedal... ide o staru rokmi preverenu funcnost, spravnu ideologiu slobody a nezavislosti a aj nieco ineho navyse ....

  • 6. 5. 2017 13:40

    klokan

    "Správná ideologie svobody" to si musím zapamatovat, to by nevymyslelo ani Rudé Právo:) A pokud jde o tu "svobodu" v čistě technických otázkách kontroly služeb a zdrojů v OS, nemyslíte, že to s tím patosem kapánek přeháníte?

  • 6. 5. 2017 15:30

    NULL (neregistrovaný) ---.freepoint.cz

    @klokan

    ""Správná ideologie svobody""

    A copak je šparné na svobodě? Přece komunity okolo GNU a Linuxu (a další... abych někoho nevynechal) se těmito ideologiemi a činy přece původně proslavily . . .

  • 6. 5. 2017 20:15

    Brepta (neregistrovaný) 109.202.80.---

    Mám za to, že mu nešlo o svobodu jako takovou, ale spojení "ideologie svobody" povýšené do levelu "správná ideologie ...". Si tedy myslím.

  • 7. 5. 2017 9:24

    NULL (neregistrovaný) ---.freepoint.cz

    Aha, no to asi bude muset vysvětlit autor, ale já to pobral tak, že tím "správnou" myslí tu "opravdovou" ideologii svobody. Těch ideologií svobody máme totiž více. Třeba ta ideologie svobody okolo systemd mi nepřipadne taková ta úplně opravdová svoboda, protože se sice můžeš svobodně rozhodnout, ale s tím, že pokud nebudeš chválit, tak nebudeš svobodomyslný člověk který tomu rozumí, ale budeš hloupý trollí neumětel, který by chtěl zpátky jednoúlohové OS, otrokářství a malé děti k večeři.

  • 7. 5. 2017 22:14

    Lael Ophir

    Ještě že se open source komunita dostala k Unixům až s Linuxem, když už bylo všechno zásadní vymyšleno, a Linus to jen opsal podle dokumentace. Jinak by Linux měl pět nekompatibilních typů kernelu s deseti různými sadami sycalls, dvacet implementací libc s minimálním překryvem funkcí, třicet nekompatibilních zobrazovacích serverů (logicky pojmenovaných ISS, Mir, Beowulf, Wayland a X11 až X96), čtyřicet formátů balíčků, padesát toolkitů pro každý zobrazovací server, sto formátů konfiguráků atd. Po nocích by se v ulicích řezaly a občas střílely skupinky příznivců Beowulfu a X23, initq a systemz, MachoKernelu a PureCore, Cairo a Tripoli, wcurses a mcurses, gpm a dec...

    Upřímně mi jako nezúčastněnému pozorovateli tyhle žabomyší války s tříštěním sil, kydáním špíny a dokonce výhrůžkami smrtí připadají tragikomické.

  • 6. 5. 2017 15:42

    Jenda (neregistrovaný) ---.net.upcbroadband.cz

    Za mě: samozřejmě, že jde o funkčnost. Podle mě potřebuje ještě několik let k tomu, aby dozrál. Udělat z toho jeden z nejkritičtějších kusů SW ve všech distribucí už teď byl podle mě velký nerozum.

    Spousta nedořešených problémů v nečekaných situacích (selhání fsck, nesestavení RAIDu, nepřerušitelný n*90 sekund timeout při nedostupné síti/disku (tj. čeká se 3 minuty navíc a až potom se admin může přihlásit na konzoli a problém opravit), nereportování chyb)

    Nedostatek návodů a howto na zvládání novinek jako journald a spousty dalších démonů (resolve, timesync, ...).

    S každou verzí očekávání co dalšího co v unixech fungovalo posledních 30 let se zase rozbije (zabíjení screen/nohup sessions po odhlášení uživatele, zrušení rc.local, „opravení“ aby halt dělal halt a poweroff dělal poweroff, převzetí ACPI eventů loginctl, který ale neumí spustit arbitrary skript, takže se musí vypnout a stejně pustit předchozí acpid).

    Unit files rozprsklé všude možně po VFS včetně generovaných za běhu s ne-obvious možností jak je overridnout.

    Blbě napsané unit files které službu nespustí a nic neřeknou a na rozdíl od init skriptů nejde triviálně udělat bash -x /etc/init.d/služba start a podívat se, na čem se to vysekalo.

    Nesmyslné enforcování ideologie i když to rozbije distribuční mechanismy (/etc/mtab musí být symlink do /proc/mounts, jenže update-initramfs čte z /etc/mtab informace o tom, kde je /. Když jsem generoval initramfs pro chrootnutý systém, tak jsem mu /etc/mtab prostě přepsal. Teď to nejde.)

    Komplikovanější dohackování funkcionality než „tady do init skriptu připíšu jeden řádek“.

    Desítky megabajtů paměti použitých novými démony (systemd --system/user, logind, journald). To fakt nikdo nečeká, že v roce 2017 existují linuxové embedded systémy, kde je tohle nezanedbatelný podíl dostupné RAM?

    Veliká enterprise architektura a obrovské množství konfiguračních XML souborů na mnoha místech po systému do které není snadné proniknout a blbě se to ladí na rozdíl od pár skriptů a symlinků v /etc/rc*.

    Vývoj veden nepříjemným vývojářem, který má mezery ve znalostech, jak funguje UNIX (1, 2)

  • 6. 5. 2017 23:56

    muf (neregistrovaný) ---.opera-mini.net

    Díky za dobré shrnutí. Podařilo se vám shrnout skoro vše, čím ta obluda otravuje i mě.
    Argumenty zastánců bývají někdy komické. Kupříkladu je prý teď krásně jednoduché vytvořit novou službu pomocí pár řádek v příslušném .service, protože nemusíte psát složité shell scripty. Všimněte si, že často je praxe taková, že zde najdete cestu právě k takovému scriptu, čímž se vtipně obchází omezení a chybovost toho nejúžasnějšího init systému všech dob.Jestli chcete vidět, jak náramně to funguje, mrkněte, jak jsou v RHEL7(CentOS) nahazována síťová rozhraní...Joo, generators, to je věc...
    Já vím, až bude vše sluníčkové a daemony a vůbec vše budeme dělat podle Poetteringa... Ten chlapec by se rád zapsal do dějin, ale prostě na to nemá. Produkuje tuny kódu, ale bez koncepce, invence, elegance. Celé jeho působení je upachtěné a proto agresivní. Vedle tvůrců Unixu zůstane navždy jen trpaslíkem.
    Celé to hnutí "za pokrok" mně připomíná levicové "liberály", kterými je v západním světě promořené humanitní vzdělávání. Je to podobné jak metodikou tak vnějšími projevy: dehonestace, urážky, nálepkování oponentů, hysterie, snaha vsugerovat, "že jinak to nejde...my jsme ti dokonalí a vyvolení..."

    Já kupříkladu nikdy netvrdil, že starý init ze systemu 5 je dokonalý a nepotřebuje náhradu. Byly tady. Například upstart jí mohl být, nebýt politiky. Ničeho jiného než politiky...

    Devuan je obdivuhodný počin.

  • 7. 5. 2017 19:09

    Sid (neregistrovaný) ---.91-127-104.t-com.sk

    Upstar o ktorom clovek co ho navrhol povedal ze je dobre ze ho nezvolili v debiane? urcite to bola politika a asi preto canonical o tyzden stoplo upstar.

  • 7. 5. 2017 19:22

    tnr (neregistrovaný) ---.cust.vodafone.cz

    Nic neukazuje vic emocialnost rozhodovani nekterych lidi proti systemd jako propagovani upstartu, projektu, o kterem jeho autori sami rekli,ze je broken by design.

    Viz komentare od Scott James Remnant,ktery rikal,ze by se to muselo cele prepsat...

    Kdyz uz chcete sd kritizovat a rikat co by se mohlo pouzivat misto nej,tak to aspon nedelejte tak hloupe a doporucujte aspon OpenRC))

  • 7. 5. 2017 9:19

    Filip Jirsák

    Blbě napsané unit files které službu nespustí a nic neřeknou a na rozdíl od init skriptů nejde triviálně udělat bash -x /etc/init.d/služba start a podívat se, na čem se to vysekalo.
    Mně teda připadá mnohem jednodušší zkopírovat ten jeden příkaz z unit souboru a spustit jej ručně, než debugovat bash skript. A obvykle to ani není potřeba, protože výstup toho příkazu najdu v logu.

  • 7. 5. 2017 10:04

    ByCzech

    Mně teda připadá mnohem jednodušší zkopírovat ten jeden příkaz z unit souboru a spustit jej ručně, než debugovat bash skript. A obvykle to ani není potřeba, protože výstup toho příkazu najdu v logu.

    Teorie krásná, blbé je, že běžně se příkaz ručně spustit dá a funguje, ale při startu přes systemd se nespustí a v logu je houbeles. To je zase praxe.

  • 7. 5. 2017 12:28

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    V sysvinitu běží služba v jednom prostředí po ručním spuštění a v úplně jiném po restartu serveru. To je ještě větší lahůdka ladit.

  • 7. 5. 2017 12:33

    Filip Jirsák

    Úplně jiné? Mohou tam být nastavené nějaké limity nebo capability, ale ty obvykle pro základní odladění nepotřebujete – a pokud ano, vidíte jejich nastavení v unit souboru. Mohou tam být jinak nastavené proměnné prostředí, ale ty opět vidíte v unit souboru.

    Moje zkušenost je taková, že když připravuju nějakou službu, nejprve si ji spouštím z shellu, služba mi běží na popředí, vidím její výstup. Když mám všechny parametry nastavené tak, jak potřebuju, jenom ten příkaz zkopíruju do unit souboru – a všechno funguje stejně, jako když jsem to pouštěl z shellu, standardní výstup vidím v logu. Když jsem to samé řešil se SysVInitem, narazil jsem typicky hned na začátku na dva problémy – za prvé, proces se typicky sám odforkováním daemonizoval, takže když jsem ho chtěl spustit z shellu, musel jsem daemonizaci zakázat – a služba se hned začala chovat jinak. Druhý problém byl, že standardní výstup byl v init skriptu typicky přesměrován do /dev/null, takže když jsem se chtěl dozvědět, co vlastně aplikace při startu vypisuje za chybu, musel jsem upravovat produkční init skript, přidávat do něj ladicí výpisy a doufat, že ho pak zase vrátím do původního stavu.

    Už před lety jsem právě kvůli tomuhle začal používat daemontools – protože už tenkrát mi připadalo šílené, že proces sám dělá něco jiného, když ho spustím ručně a když ho spustím pod správcem procesů. Mimochodem, řekl bych, že to, že spousta serverů implementuje daemonizaci, vypovídá o „kvalitě“ běžně používaného správce služeb – když serverový proces první, co udělá, je to, že se forkne, aby se dostal z dosahu správce služeb…

  • 7. 5. 2017 18:02

    kozec

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

  • 7. 5. 2017 18:36

    Filip Jirsák

    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?

  • 7. 5. 2017 19:02

    kozec

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

  • 7. 5. 2017 19:18

    Sid (neregistrovaný) ---.91-127-104.t-com.sk

    Ano, dokonca nie kazdy potrebuje pristupove prava, firewall a milion dalsich veci. Akurat je otazne ci specificky dovod alebo obcas blbost ma sluzit ako argument.

  • 7. 5. 2017 19:30

    Filip Jirsák

    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.

  • 7. 5. 2017 20:02

    kozec

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

  • 7. 5. 2017 20:24

    tnr (neregistrovaný) 193.165.237.---

    No,ze jsme to prezili bez neceho jako systemd je sice pravda, ale podil linuxu na desktopu taky o necem mluvi )) to neni vubec jen o sd, ale o pouzitelnosti novych technologii v kombinaci sd,wayland a jejich pro desktop moc neni potreba mluvit.. Sysvinit a treba podpora dynamicky pridavaneho hw, skoda mluvit.

    A i ta sprava serveru je dneska dost jina,davno jsou pryc doby,kdy jeden admin spravoval par uber serveru, kuchtil si shell skripty a customizoval. Dnesni velke firmy chteji mnoho virtualizovanych standardnich serveru, kontejnery, automaticke deploymenty serveru a centralizovanou spravu.

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

  • 8. 5. 2017 10:41

    kozec

    > 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

  • 8. 5. 2017 12:28

    tnr (neregistrovaný) 193.165.237.---

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

    Ne, ale o tom ze veci nefunguji, dokaze vedet docela hodne :-) Viz vsemozne, neresitelne problemy napr. bez logind.

    >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

    Me to funguje docela dobre :) Dej priklad unity, ktera je nekompatibilni. Samozrejme muze byt problem verze systemd, ale to se 99.9% unit vubec netyka. A proc teda vubec treba vyvojar Archlinuxu rika, ze jim systemd vyrazne ulehcil praci pri sprave unit?:)

  • 8. 5. 2017 12:50

    Filip Jirsák

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

  • 8. 5. 2017 16:51

    kozec

    > 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 :)

  • 8. 5. 2017 17:34

    tnr (neregistrovaný) 82.202.112.---

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

    To je mimoriadne relevantne :) Napr. stabilni ukonceni sezeni jednoho, vicenasobne prihlaseneho uzivatele, se vsemi procesy z tohoto sezeni (vcetne forknutych), cely multiseat management atd. Ono ne ze by se to nedalo pouzivat i bez toho, ale je to podobne jako s jinymi vecmi ze systemd - jde to nabastlit i bez nich, ale robustni reseni to neni.

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

    > Len prva vec co vyplul vyhladavac :)

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

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

    False.

    Cituji 2brainz (vyvojar zodpovedny za init v Archu v te dobe):
    > Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us.

    Tzn. jasne pise, ze pouziti systemd a moznost sdileni teto spolecne funkcionality s vetsi komunitou znamenalo zjednoduseni jejich prace (oproti bastleni init skriptu na kolene).

  • 8. 5. 2017 20:14

    kozec

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

  • 9. 5. 2017 6:16

    tnr (neregistrovaný) ---.cust.vodafone.cz

    > 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

    Ano? A jak ten tvuj skript o 5 radcich pozna u forknuteho procesu X pri 2 sezenich stejneho uzivatele, zda ho killnout ci nikoliv :)

    A jinak zadana featura to docela byla, na desktopech byl mizerny multiseat a leftover procesy zdrojem docela beznych problemu...

    > ATTRS{vendor}=="ni­eco" ATTRS{model}=="ni­eco-ine" RUN+="service start nejaka-sluzba"
    > To hadam ani nebolo myslene vazne :)

    Tak a ted se zamysli, jak to resi napr. zavislosti te sluzby, jak to osetruje paralelni spusteni v pripade, ze se takovato sluzba (ci jeji zavilosti) spusti z vice hw eventu atd.No, nijak, obet v minulosti bezny zdroj problemu :)

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

    Jiste, protoze init.d skripty se mezi distribucemi typicky lisily prave jenom zmenenyma cestama a nikoliv treba pouzitymi knihovnami a vubec nebyly uplne odlisne v distribucich :) A nemluve o tom, ze zmena konfiguracnicho souboru (unit) je mnohem jednodussi nez zmena provadeneho skriptu (ktery muze byt vice ci mene zprasen a typicky bude mnohem delsi - staci se podivat na init.d skripty pred systemd treba v redhatu ci debianu - obcas i stovky radku provadeneho kodu).

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

    Opet cituji:

    >So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution.

    Prispevek je z roku 2016, nikde nepise, ze mu predpoklad nevysel :)

    > Co take?

    Nepochopil, nevadi :))

  • 7. 5. 2017 21:19

    Filip Jirsák

    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.

  • 8. 5. 2017 11:18

    kozec

    > 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 :)

  • 8. 5. 2017 11:43

    Filip Jirsák

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

  • 8. 5. 2017 17:14

    kozec

    > 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

  • 8. 5. 2017 17:42

    Filip Jirsák

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

  • 8. 5. 2017 20:31

    kozec

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

  • 8. 5. 2017 21:12

    Filip Jirsák

    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?

  • 8. 5. 2017 17:45

    tnr (neregistrovaný) 82.202.112.---

    > 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 :)

    Delat je to nikdo (a rozhodne ne systemd) nenuti. 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.

    > Je to v podstate lepsie navrhnuta verzia toho, co so sluzbami robi Windows.
    Souhlasim, konecne v Linuxu je neco, co dokaze podobne uzitecne funkcionalite z Windows konkurovat a neni to nutne resit v kazdem serveru zvlast (a povetsinou vic ci mene blbe)

    > Hovadina. Auta vytlacili rebrinaky rychlostou, nie jednoduchostou. "Lepsie" a "jednoduchsie" su dve celkom rozdielne metriky.
    Hezky priklad. A systemd vytlacil ostatni init systemy rychlosti, komplexnim resenim beznych situaci a jednoduchosti pro autory distribuci a uzivatele. Ale samozrejme se vzdy najde nejaky pomatenec, co v tom hleda konspiraci RedHatu / Microsoftu / Zednarske loze / .... Ale uz nikdo nedokaze vysvetlit, co by z toho treba ten RH mel - mohli si klidne nechat systemd jako proprietni reseni, stejne tak ho zadna distribuce nemusela pouzivat, RedHat nikomu nuz na krku nedrzel (a ano, pokud duvodem je snaha usetrit vlastni zdroje, abych mohl pouzivat co nejvice prace od RH bez nutnosti zmen a vlastni invencne, tak v takovem pripade proste smula - bud to musi akceptovat, nebo si platit vlastni vyvojare).

    > Podstatnost tejto malickosti uz bola demonstrovana tak silne, ze do SystemD pridali kod restarujuci system pri pade :)
    A? Normalni soucast zakladniho core systemu skoro vsude.

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

    Init nepotrebuje, moderni zaklad systemu ano. Je proste holt potreba se smirit s tim, ze system postaveny na bastleni shell skriptu a neposkytujici komplexni funkcionalitu pro sluzby vc. API pro automatizaci (kam presne takove veci, ktere SD resi, patri), dnes nikdo z velkych Linuxovych hracu (a jejich zakazniku) proste nechce...

  • 8. 5. 2017 20:40

    kozec

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

  • 8. 5. 2017 23:47

    Lael Ophir

    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.

  • 9. 5. 2017 7:10

    NULL (neregistrovaný) ---.freepoint.cz

    @Ophir

    To je stejná pitomost, jako kdyby jsi napsal, že každý kdo nechce poviné kvóty na počty žen v jednotlivých zaměstnáních, tak tvrdí, že ženy patří jenom do kuchyně.
    Stejně je to trošku laciné rovnítko, když je init špatný, tak je prostě systemd dobrý i kdyby . . . . To promiň, ale to je kritérium jak ......

  • 9. 5. 2017 10:58

    NULL (neregistrovaný) 91.187.42.---

    @Kate

    A jak pak se v tomto případě "tenhle styl správy služeb", o kterém je tu řeč150+ příspěvků, jmenuje?

    Ale to se systemd nebyla přímo reakce na @Laela, ale tak celkem povzdychnutí k tomu stylu 'Argument " dělá se to tak od roku 1979, takže to musí být správně" nějak neberu', protože z toho okamžitě čiší argument "To že je to staré neznamená automaticky že je to špatné" a ani to že "je to nové, neznamená automaticky že je to dobré". A to, že je to staré řešení špatné ještě neznamená, že kdejaký bastl nový je automaticky lepší. Může a nemusí, ale hodnotit to podle stáří . . . ach jo.

  • 9. 5. 2017 6:35

    tnr (neregistrovaný) ---.cust.vodafone.cz

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

    Jenze systemd nefunguje na par specifickych konfiguracich Linuxu, ale na vsech majoritnich distribucich :) Takze pokud nemam v planu multiplatformnost, muzu klidne pouzit systemd API primo a neresit milion veci, ktere uz resi systemd.

    > Vlastne si takuto hovadinu pred SystemD dovolil spravit iba Windows :)
    Nebo to treba dela Mac OS X - takze vlastne 3 majoritni systemy (Windows, Mac OS X, majorita Linuxovych distribuci).

    Ale jinak podpora watchdogu je uplne v kazdem systemu, i treba v FreeBSD (watchdogd), je to normalni soucasti systemu uz dekady.

    > ... rovnako ako v 90-tych rokoch vytlacil Unixy technicky vyspelejsi OS od Microsoftu. To bol sarkazmus, mimochodom.
    Tvuj sarkasmus je mimo, vytlacil spoustu existujicich reseni, protoze byl technicky lepsi a univerzalnejsi (napr. NetWare), lepe se integroval s klienty (NT domain, pozdeji ActiveDirectory) ci byl pro spoustu firem proste jednodussi na spravu (SMB).
    Naopak nevytlacil tam, kde technicky nezaril - prave specializovane servery, webove (ale casto i aplikacni) servery, firewally, routery atd. Tam vsude zustaly bud specializovane operacni systemy nebo zustaly dominantni UNIXy a MS mel smulu.

  • 6. 5. 2017 22:31

    kozec

    SystemD je neuveriteľný galimatiáš kódu a komponentov, ktoré sú síce teoreticky samostatné, ale v praxi prepojené a neoddeliteľné jeden od druhého. Vytvára tak single point of failure bežiaci na privilegovanej vrstve, masívny, prakticky neauditovatelný a spoločný pre viaceré distrá.

    Jeho hlavnou devízou nikdy nebola technická vyspelosť, ale fakt, že sa ho podarilo politicky presadiť do dvoch hlavných distribúcií. Za jednou z nich stojí firma čo riadi jeho vývoj.

    SystemD je prakticky antitézou k Unixu. Namiesto "do one thing and do it well" máme systém, ktorý zvláda mnoho, ale väčšinu na hovno. Mnoho komponentov bolo čiastočne nahradených funkciami SystemD a následne odstránených, takže k dispozícii ostala len čiastočná funkčnosť. Akékoľvek ladenie je zážitok, nakoľko chyby sa zásadne prejavujú v komponentoch ktoré ich nespôsobili. Pokiaľ Vám napríklad po nabootovaní občas nefunguje sieť, nemusí to byť nutne problém v NetworkManageri. Môže to spôsobovať SystemD reimplementácia mountovania a fakt, že sa niektoré súbory vo VFS zjavia až po tom, ako sa ich dhcpcd pokúsi prečítať.

    Stále viac a viac komponentov má na SystemD nevysvetliteľné závislosti, takže sa dostávame do podobného vendor-lock-inu ako s Windows. Pokiaľ si zvolíte distro s technicky lepším init systémom, môže sa Vám stať, že nebude fungovať zvuk, pretože ovládací panel pulseaudia závisí na SystemD. Alebo vtipnejší príklad, Snap, nový balíčkovaní systém Ubuntu, stavia na architektúre kde kľúčový démon spustený inak, než so SystemD, bez chybovej hlášky spadne.

    Tím za SystemD trpí šialeným prípadom "NIH syndrómu" a neustále sa snažia vynachádzať koleso, necápajúc pri tom prečo by malo byť guľaté. Pekným príkladom je napríklad ich verzia "rm", ktorá donedávna pri rekurzívnom mazaní pokladala ".." za podadresár a snažila sa rekurzívne zmazať celý disk.

    A toto všetko je vystupňované na n-tú nepochopiteľnou aroganciou vývojárov, ktorá si nezadá ani s prístupom ľudí za prostredím Gnome. Diskusia nieje prípustná, za problémy môže zásadne niekto iný. Proste sranda, aspoň kým to človek môže pozorovať z ďaleka :)

  • 6. 5. 2017 13:27

    cutile (neregistrovaný) 92.62.225.---

    Co konkretniho je za problem s KDE, predpokladam vetev 4.x ?

    Pokud vim, distra bez systemD jako Slackware nebo Void Linux dodavaji KDE4 uz dlouho a bez nejakych divokych patchu.

    Zacinam pochybovat o jejich kompetentnosti nebo nemaji manpower aby opravovali zprasene Debiani balicky, zbytecne natvrdo zadratovane.

  • 6. 5. 2017 13:49

    Lukáš Turek

    Na Gentoo mi bez problémů běží i KDE5 bez systemd. Ale pro uspávání a hibernaci je potřeba ConsoleKit2, který v Debianu není, a nejspíš toho bude víc. Samotné KDE ale rozhodně systemd nepotřebuje, když funguje na FreeBSD a nějak snad i na Windows.

  • 6. 5. 2017 14:59

    mhepp (neregistrovaný) ---.vpn.muni.cz

    Asi jako jeden z mála jsem zastáncem obou stran. Popravdě řečeno, vidim výhody obou světů, ale i jejich nevýhody. Pokud bych si mohl ale vybrat, jakože už nemůžu, tak bych si vybral linux bez systemd. Proč? Pro agresivní politiku při jeho prosazování. Já chci mít na výběr, ale už nemám.

    No a pár argumentů, které vnímám...

    Systemd je dobrý pro desktop, kde potřebuji jako uživatel mít přístup k různým věcem, chci rychlý start, udev, protože připojuji různá zařízení, dbus, protože o nich chci vědět a network-manager, protože se stěhuji mezi sítěmi. Také dynamické pouštění služeb podle potřeby a tak. V tom mi systemd může pomoci.

    Na druhou stranu mám nemalou farmu serverů na starosti. Běhové prostředí takového systému je neměnné, protože služby naběhnou při startu a běží do vypnutí. Síť je obvykle staticky nastavená (staticky z hlediska konfigurace -- při instalaci serveru nastavím síť a je to obvykle validní nastavení po celou životnost serveru). Pak je mi ku ho*nu network-manager, protože nastavení sítě obvykle zvládne maximálně 5, vyjímečně 10 příkazů někde ve skriptu. Zařízení nepřipojuji, není jak. Za to ale potřebuji, aby server zvládl restart. Zde je pro mne systemd na obtíž. Některé služby se nepustí, jiné se odmítají restartovat, některé se nevypnou. Restart serveru je sázka do loterie, jestli se vypne. Obvykle zamrzne ve stavu, kdy to znamená potřebu fyzického přístupu, který je často obtížný, až nemožný. Tot berte jako zkušenosti z praxe napříč distribucemi a jejich verzemi. Proto mám klíčové servery pořád se systemV initem.

    Většina z vás jsou Linuxáci, tudíž vám tyto věci přijdou v pohodě. Ale podívejte se na to z pohledu uživatele Gnome třeba ve FreeBSD. Aktuální verze Gnome je natolik závislá na systemd, že není možné používat aktuální Gnome jinde, než v Linuxu. *BSD-čka, jděte do zadeke. U KDE5 je situace podobná, ale není tak zlá... A toto už neni v pořádku. U Gnome je jasný zájem RedHat-u, jak je to s KDE nevím.

    Většina ostatních argumentů pro/proti systemd/sysVinit jsou dle mne jen projevy nenávisti a neochoty akceptovat svobodu volby pro druhé.

  • 6. 5. 2017 15:38

    NULL (neregistrovaný) ---.freepoint.cz

    Hezky napsané. Mám s tím ten samý problém: Kdo si dovolí se ozvat je hater nebo hlupák (jak časté v dnešní době) a to že je to tak zadrátované do systému - a to se projevuje třeba tím, že to ze serverů nejde jen tak vykopnout. Zatím nějak jde, ale takovým tempem a směrem . . .

  • 6. 5. 2017 22:59

    Stefan (neregistrovaný) ---.tmcz.cz

    No já vám nevím, staráme se o skoro stovku virtuálů s Centos7 a network-manager je první co odinstalováváme protože není potřeba, takže pokud ho nepotřebujete proč ho používáte ? :O)
    Ohledně Systemd a restartů tak nevidím na žádném serveru žádný problém, prostě dám reboot a po chviličce se zase na server přihlásím. Jak jsem psal již mnohokrát přechod z Centos6 na Centos7 byl naprosto bezproblémový, místo starých 20-50řádků skriptů v /etc/init.d máme 5-15řádkové konfiguráky v /etc/systemd/system a vše funguje tak jako dříve.

  • 7. 5. 2017 2:16

    NULL (neregistrovaný) ---.freepoint.cz

    @Stefan

    Gratuluji, vážně, ale nemyslím si, že ti co mají se systemd problémy jsou lháři nebo hlupáci, jinak si to totiž nelze vysvětlit, když je systemd teda bezproblémový.

  • 7. 5. 2017 9:15

    Filip Jirsák

    Kolik jste zaznamenal případů, kdy někdo používal nebo používá systemd a měl s ním problémy? Většina kritiků v diskusích nepopisuje, že by oni konkrétně měli nějaký problém při provozu systemd. Kritizují koncepční věci – že je systemd velký moloch a odporuje unixové filozofii, že jedna komponenta má dělat jen jednu věc; že se systemd skládá ze spousty komponent; že se vyvíjí moc rychle; že se vyvíjí moc pomalu; že má údajně nestabilní veřejné API; že by měl dělat přesně to samé, co dělá SysVInit…

  • 7. 5. 2017 9:48

    NULL (neregistrovaný) ---.freepoint.cz

    @Jirsák

    No promiň, ale nejsem internetový statistický úřad na bugy systemd. Takže jaké číslo bys po mě jako chtěl?

    Jak nepopisuje? Už jenom tady v diskuzi několik lidí píše jaké s tím měli problémy. A To že mu někdo odepíše - mě to jede normálně - neberu jako vyčerpávající důkaz že se plete.
    Ale problém bude opět a zase spíš v tom, že abys mohl klást takové otázky, na které stejně opravdu nehledáš odpověď a nenecháš se přesvědčit a budeš zase jenom zatahovat a polokroutit další a další věci jako obvykle, požadovat vyčerpávající výpisy z dokumentace, bugzilly a důkazy na každé slovo kromě "aby" a "se", tak je potřeba ty komenty kde se konkrétně něco zmiňuje tak trošku přehlédnout - takže ještě jdnou: "ž jenom tady v diskuzi několik lidí píše jaké s tím měli problémy".

    A já osobně si pamatuji, že často lidi popisují, že jim po restartu nestarují služby a to se stalo i mě - 2x a když máš během 2 dnů zpracovat nějaký prototyp na něčem co ti systemd spustí, pak občas nespustí, občas nerestartuje, občas nejde vypnout a pak se nezapne, tak nemáš čas na nějaké dlouhé debugování a zjišťování - klienta totiž nezajímá že o systemd se nepochybuje, je skvělý, je přínosný a tak musíme mlčet. 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.

  • 7. 5. 2017 10:08

    Filip Jirsák

    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.

  • 7. 5. 2017 12:26

    NULL (neregistrovaný) ---.freepoint.cz

    "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 už to zas začíná, Jirsákovo otravné kolečko, které nemá jiný účel než otavovat a otravovat se zjevnýma věcma A odpověď? Dokonce se o tom píše hned v prvním příspěvku u toho vlákna ve kterém toto píšeš. To ses neobtěžoval ani toto si přečíst? To se pak nedivím že o ničem (jaká náhodička zase) nevíš.

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

    Už jsme to tady dokonce jednou řešili.Proč si to myslím? Tak si to shrneme:
    1. z shelu službu spustím a vypnut - ok
    2. podle návodu nastavím unit file - ok
    3. spustím přes systemctl - běží - ok
    4. restartuji přes systemctl - běží -ok
    5. vypnu přes systemctl je neběží -ok
    6. večer vypnu pc a ráno zapnu - neběží - fail
    7. ručně přes systemctl zapnu - běží - ok
    8. přes systemctl restartuji neběží - fail
    9. zapnu přes shell - běží - ok
    10. vypnu přes shell - neběží - ok
    11. restartuji pro jistotu PC
    12. neběží -fail
    13. přes systemctl zapnu - běží -ok
    14. přes systemctl restartuji - už zase neběží - ok

    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.

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

    Ale ano. Já to tvrdím.

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

    1. popisuji to výše
    2. ok, může se to dít i s initem ale kde je pak ta super výhoda proti initu? (Tím nemyslím aby jsi mi vyjmenovával všechny ostatní věci do kterých krom initu se systemd vesr.)

  • 7. 5. 2017 12:58

    Filip Jirsák

    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.

  • 7. 5. 2017 13:36

    NULL (neregistrovaný) ---.freepoint.cz

    "Chápu, že pro vás je otravné, když po vás někdo chce, abyste svá tvrzení dokládal"

    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á. Za chvilku po mě budeš chtít všechno notářsky ověřovat. Ovšem od člověka, který každý svůj výrok považuje za fakt a kdo to neuzná a trvá na svém se stává lhářem, co čekat . . .

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

    Ano, a protože jsem ji nepovolil (povolil podle toho návodu), tak se občas po restartu pustila. Teď akotár nevím, který z těch stavů je špatně: jestli se povolená služba občas nespustí, nebo se nepovolená občas spustí - asi si můžu vybrat.
    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.
    Ale netvrdím, neviděl jsem v životě a sám jsem ani nikdy nevyprodukoval kód, kdeby nebyla nějaká chyba. 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.

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

    A na co by ji měl? Mě by stačilo kdyby dělal to co je v unit file.

  • 7. 5. 2017 14:02

    Filip Jirsák

    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.

  • 7. 5. 2017 15:17

    NULL (neregistrovaný) ---.freepoint.cz

    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?

    To že všechno označuješ za doměnky a podsouvání je tvůj problém. Když údajně nedoložím že to tak je, jak teda můžeš vědět, že to tak není?
    Nemůžeš, jenom si to myslíš a podsouváš mi svůj dojem jako nějaký závěr který bych snad já, protože si veličenstvo dovolí nesouhlasit, musel nějak prokazovat a to ještě tak, aby to veličenstvu vylo dost dobré.

    Dokaž mi že lžu když to tvrdíš.

  • 7. 5. 2017 15:48

    Filip Jirsák

    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.

  • 7. 5. 2017 16:01

    tnr (neregistrovaný) ---.cust.nbox.cz

    Pokud tvrdis X (ze za to muze systemd), tak je na tobe aby jsi to dokazal, napr. linkem na bugreport. Jinak je to prazdne tvrzeni a neda se divit,ze ti to moc lidi nebude verit jen proto,ze to rikas. Bugy jsou v kazdem sw, sd neni bez vad, ale tohle ne proste prazdne tvrzeni...

    Ja tvrdim,ze pouzivani openrc zpusobuje vrazdy nemluvnat administratory. Dokazte mi, ze to tak neni)) blbost,ze? Ale tvuj vyrok je na tom uplne stejne, pokud ho nepodlozis nejakymi tvrdymi daty, jinak jsou to pouze tve dojmy, ktere mit muzes, nikdo ti je nebere, ale tez je tezko nekdo bude brat jako fakta...

  • 7. 5. 2017 16:41

    NULL (neregistrovaný) ---.freepoint.cz

    @tnr

    Tvrď si co chceš, já jsem nepřilezl ti tvrdit opak a nepožaduji po tobě na to důkaz.

    @Jirsák

    "Nepochopitelné na tom je, proč si myslíte, že za to může systemd"

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

    "Zkušenost. Vy jste nenapsal jediný důvod, proč by to měla být chyba system"

    po 5.
    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 . . . .
    Ale ty jsi nenapsal jediný proč by nemohlo. Dojem je jenom dojem. Nicméně jsem to zkoušel dohledat, ale po činu jsem to důkladně "vyčistil". Takže bohužel.

    "Nemůžu za to, že si myslíte, že jediný, kdo může zpochybňovat vaše tvrzení, je nějaké veličenstvo."

    Mé názory může zpochybnit kdokoliv a taky se to často děje. Několikrát jsem ti napsal proč si myslím že je to způsobeno systemd, bez výsledku. 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.

    Že lžu jsi netvrdil, to bylo v jiné diskuzi, že ano, takže za to pardon.

  • 7. 5. 2017 17:00

    tnr (neregistrovaný) ---.cust.nbox.cz

    Pokud nejsi schopen prinest do diskuse tvrda fakta, kterymi podporis tvoje tvrzeni, tak je bohuzel diskuse zbytecna a spada do kategorie FUD.

    A to neni vubec o systemd, to je proste platny argument pro jakoukoliv diskuse o cemkoliv, o tom, kdosi co mysli, ze za neco muze, muzeme diskutovat donekonecna a k nicemu to nebude... Protoze objektivne to shodnoit stejne nepujde,ani z toho nemize vzniknout zadne zlepseni...

  • 7. 5. 2017 18:29

    NULL (neregistrovaný) ---.freepoint.cz

    @tnr

    Nevím o tom, že bych tě k něčemu nutil. Já dal svoji zkušenost a prokázat už ji nemám jak. Jestli ti to nevoní, tak co jako, musím se tě dovolit než to někde napíšu?

  • 7. 5. 2017 18:40

    Filip Jirsák

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

  • 7. 5. 2017 18:50

    NULL (neregistrovaný) ---.freepoint.cz

    @Jirsák

    To ale napsat nemůžu, to bych opravdu lhal, protože si to nemyslím a vyloučovací metodou jsem došel k tomu, že je to chyba systemd. To mě ale netrápí, podobné chyby mohou nastat kdekoliv, na systemd mi vadí něco úplně jiného. Řešilo se milionkrát, vyřešilo se prd a jelikož nepřispívám do systemd nebo Debianu, musím systemd chválit nebo mlčet. Chválit bohužel nemohu.

  • 7. 5. 2017 22:20

    NULL (neregistrovaný) ---.freepoint.cz

    Samozřejmě. Klasicky hned jako první. Ale asi není moc logické po tom, co něco nastavíš, a funguje jak má, do toho vrtat aby to fungovalo jak má.

  • 8. 5. 2017 9:20

    NULL (neregistrovaný) ---.freepoint.cz

    Od začátku ti píšu, že to fungovalo jak má až na občasné výpadky. Takže mám měnit konfiguraci aby to nefungovalo jak má a občas fungovalo?

    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".
    Ty jsi možná chytrý člověk, ale jakmile přijde na to se s někým bavit, tak jsi úplná *********

  • 8. 5. 2017 9:27

    tnr (neregistrovaný) 193.165.237.---

    Od cloveka, ktery tu neco tvrdi, co neni schopen dokazat ci alespon nejak podlozit, je to prinejmensim usmevne...

    Misto toho, aby jsi dokazal co tvrdis (coz je zcela normalni v diskusi od kohokoliv, ze kdyz tvrdim X,tak to musim necim podporit) a capis se tu jak maly kluk,kdyz to ostatni (opravnene) zpochybnuji...

  • 8. 5. 2017 11:15

    NULL (neregistrovaný) ---.freepoint.cz

    @tnr

    Už jsem několikrát napsal že jsem službu už dávno odstanil a unit file smazal. Jak to mám prokázat? Tvrdíš že to není tak jak říkám? Prokaž to . . ..

  • 8. 5. 2017 9:33

    Ondra Satai Nekola

    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.

  • 8. 5. 2017 11:11

    NULL (neregistrovaný) ---.freepoint.cz

    @Ondra Satai Nekola

    Bohužel, jak už jsem psal, potřeboval jsem to na několik dnů na prototyp a pak jsem to odstranil. Někde to vyrábět znova a tvrdit, že je to ono, řekl bych nemá smysl. Aspoň pro mě teda ne.

  • 8. 5. 2017 9:45

    Filip Jirsák

    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.

  • 7. 5. 2017 17:13

    Filip Jirsák

    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.

  • 7. 5. 2017 18:44

    NULL (neregistrovaný) ---.freepoint.cz

    @Jirsák

    Po 6.

    Nainstaloval jsem to, rozjel jsem to, používal jsem to, ale prostě občas (během několika dnů) to občas přes systemctl spustit šlo, občas ne, občas nešlo restartovat. Ručně (konzole/sestřelit) to šlo vždy. Žádné změny unit file ani nastavení služby. 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). Jediný článek řetězu který je v tom proměný je systemctl. Důkaz nemám. Buď jsi schopný tento odstaveček pochopit > co mě vede k tomu že je to systemd chybka a nebo ne, každopádně je mi to jedno, už jsi mého času vyplítval dost.
    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. Podle mě je systemd špatný z úplně jiného důvodu, ale ať tak nebo tak s tebou a tvými otázkami "jakože netušíš o co jde a co se komu může nelíbit" (po všech těch diskuzích které už proběhly) ztrácet čas dál nehodlám. Stejně je mi vlastně u ***** co si o tom myslíš. Buď napíšeš do redakce aby mě zablokovaly a 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áš.

  • 7. 5. 2017 18:55

    Filip Jirsák

    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.

  • 7. 5. 2017 22:28

    NULL (neregistrovaný) ---.freepoint.cz

    "Jediný článek řetězu který je v tom proměný je systemctl."

    Ne, proměný tak, že jednou něco spustí, pak zase ne. Opakuji
    "Nainstaloval jsem to, rozjel jsem to, používal jsem to, ale prostě občas (během několika dnů) to občas přes systemctl spustit šlo, občas ne, občas nešlo restartovat. Ručně (konzole/sestřelit) to šlo vždy. Žádné změny unit file ani nastavení služby"

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

    Pak se div že lidi reagují jak reagují. Aspoň si laskavě přečti co ti někdo píše Takže po 8. a naposledy

    "Nainstaloval jsem to, rozjel jsem to, používal jsem to, ale prostě občas (během několika dnů) to občas přes systemctl spustit šlo, občas ne, občas nešlo restartovat. Ručně (konzole/sestřelit) to šlo vždy. Žádné změny unit file ani nastavení služby. 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). Jediný článek řetězu který je v tom proměný je systemctl."

    A speciálně pro tebe: proměný - jeho chování se měnilo.

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

    Tak mi dokaž že to zapříčiněno systemd nebylo, jinak budu dál psát, že píšeš nesmysly - jelikož nemáš přístup k mému systému, tak to nemůžeš vědět, tedy čistě vaříš z vody. Teda pardon, z křišťálové koule jménem vlastní pocit.
    A nebo, prostě budeš respektovat co píšu, tak jako já respektuji co píšeš ty a nechci po tobě na každé tvrzení důkaz (a jako první bych chtěl důkaz že to skutečně bylo chybnou konfigurací, když tedy hodláš tvrdit že jsou to výmysly)

  • 8. 5. 2017 8:55

    Filip Jirsák

    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.

  • 8. 5. 2017 9:39

    NULL (neregistrovaný) ---.freepoint.cz

    @Jirsák

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

    To je diskuze. Nepříjemná je v tom, že přileze nějaký nazdárek Jirsák a 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). Což ale absolutně nezabrání nazdárkovi tvrdit že je vše jinak a on ví nejlíp co se dělo.

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

    Ano, co popisuji se mi stalo, v logu bylo prd. Ty jsi u tohho ani nebyl, ani nemůžeš mít logy, pořád tvrdíš že to nechápeš ale klidně učiníš závěr a ještě mi ho předhazuješ jako pevný jak nějaký výsledek výzkumu.

    "if (rand() > 0.5)) exit(0);"

    To je matematický model chování systemd? To by tak dle mé zkušenosti v tom případě odpovídalo . . ..
    A navíc jsem ti psal, že po spuštění ručně se to chovalo normálně (ale zase jaksi zafungovala selektivní slepota a nepamatujeme si to) a psal jsem ti, že jsem to používal několik dnů, 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". Tedy se buď potvrzuje co říkám a nebo tu máme službu která jede total random.

  • 8. 5. 2017 10:11

    Filip Jirsák

    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.

  • 7. 5. 2017 22:53

    ByCzech

    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

  • 8. 5. 2017 9:55

    NULL (neregistrovaný) ---.freepoint.cz

    @ByCzech

    "Dík že ses mě zastal, náčelníku" :-)

    Nezapomenu na jeho výrok v diskuzi na rootu: "Napiště mi co si myslíte a já vám napíšu proč je to špatně"

    To mluví za vše. Člověk něco napíše, on mu začne tvrdit že to tak není, začne požadovat důkazy na cokoliv ho napadne, na co člověk nedodá, to je automaticky lež (protože jak mi jednou napsal: "už jsem vám to vysvětlil, takže to víte a pokud dál tvrdíte něco jiného, tak tím pádem už lžete."), co člověk dodá, tak tam už se něco najde. Pak přeopakuje člověkovy tvrzení tak, aby to odpovídalo tomu jak on si to vyčetl (co se nehodí se "zapomene", nevidí nebo přeskočí) a už to jede. Momentálně jsme ve stádiu, kdy zavede nějaký napůl ustřelený příklad a další člověkovy tvrzení už bude konfrontovat s tím příkladem jako nějakým etalonem normálnosti.

  • 7. 5. 2017 10:31

    Kár Pil Jif (neregistrovaný) ---.boingboing.net

    zaznamenal jsem do dnešního dne 1747 problémů a k tomu ještě 626 neopravených problémů

    tady je jejich seznam

    https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue

  • 8. 5. 2017 13:37

    lachtan (neregistrovaný) ---.natur.cuni.cz

    Ubuntu 17.04 - obrovské problémy se sítí, nefunkční wifi, poté, co jsem jí víceméně rozchodil (aspoň občas), tak náhodné výpadky až naprostá nefunkčnost DNS. Musel jsem se vrátit k 16.04, poprvé kdy jsem se musel vrátit k nižší verzi. Je to určitě jen náhoda, že 17.04 přešla na systemd-resolved?
    A že je to jen u mě? Zkuste třeba tu: http://www.hecticgeek.com/2017/04/ubuntu-17-04-systemd-dns-issues/
    https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1679535

  • 8. 5. 2017 14:01

    tnr (neregistrovaný) ---.net.upcbroadband.cz

    Jasne. Chyba v iwlwifi a spatne dns (rozbity dnssec, podle popisu ani unbound tam nefunguje dobre), ale muze za to systemd....

    Ten systemd musi byt asi fakt dobre napsany, kdyz se na jeho ocernovani musi lidi uchylovat k takovym hovadinam )))

    Ne ze by systemd nemel bugy jako kazdy jiny sw,ale toto je proste ehm...

  • 8. 5. 2017 16:57

    Fanous (neregistrovaný) ---.cust.vodafone.cz

    No jde o to, jestli to je chyba v iwlwifi nebo spis v Networkmanageru (=systemd)...

  • 8. 5. 2017 18:07

    tnr (neregistrovaný) ---.gw.selfnet.cz

    A borci z gnome maji se systemd spolecneho presne co?)) Nebo je soucasti systemd i wayland a freetype a vse ostatni z freedesktop.org?)))

  • 8. 5. 2017 18:38

    Fanous (neregistrovaný) ---.cust.vodafone.cz

    Borci z gnome maji docela hodne spolecneho se systemd, networkmanagerem a freedesktop.org, ne? Prave vytvareni zavislosti mezi temito komponentami je to, co je na systemd (a gnome) nejvice kritizovano.
    Tak ze sebe nedelej hlupaka tim, ze se tvaris, ze to spolu nesouvisi...

  • 8. 5. 2017 18:55

    tnr (neregistrovaný) ---.gw.selfnet.cz

    A borci z kde jsou vlastne taky borci z gnome, protoze na systemd zavisi taky?)))

  • 8. 5. 2017 17:48

    tnr (neregistrovaný) 82.202.112.---

    Od kdy je NetworkManager soucast systemd ? :-) Nema ciste nahodou systemd svuj networkd pro jednoduche, staticke konfigurace (ala drive na RH ifcfg soubory).
    Pomineme detail, proc se NM maskuje v nezavislem repozitari a ze systemd funguje zcela bez problemu bez nej (a spoustu lidi to tak pouziva).

  • 6. 5. 2017 23:16

    # (neregistrovaný) ---.net.upcbroadband.cz

    Jenze v tvym prispevku zaznivaji veci jako udev, managment siti etc ... toto presne fungovalo predtim, nez to systemd pohltil, uz chapes co je spatne? Spatne je, ze nejde pouzit udev sam (existuje nastesti fork eudev, ale kurva proc?) etc ...

  • 7. 5. 2017 9:25

    mhepp (neregistrovaný) ---.cust.vodafone.cz

    Pokud reagujes na mne, tak to jsou veci, kterych si jsem vedom. Ja systemd neobhajuji, nemam ho rad, ale chapu, ze prinesl veci, ktere jsou za jistych podminek zajimave. Ale chci mit moznost volby, ktera mi byla vzata.

    Jinak, naprosto souhlasim s tim, co napsal Jenda (doufam) a jeste bych pridal rozbijejici se a nedostupne logy v journalctl.

  • 7. 5. 2017 12:30

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    Udev jde použít sám úplně bez problémů. Eudev je fork odstraňující závislost na GNU libc, ne na systemd.

  • 7. 5. 2017 15:04

    # (neregistrovaný) ---.net.upcbroadband.cz

    Mozna se v tomto pletu, ale budto to tak nebylo vzdy nebo je tezky napr s OpenRC udev pouzivat viz prvni odstavec https://wiki.gentoo.org/wiki/Eudev

    It is a fork of systemd's udev with the goal of obtaining better compatibility with existing software such as OpenRC, Upstart, older kernels, various toolchains, and anything else required[2] by (but not well supported through) udev. Configurations utilizing systemd should not use it.

    V kazdym pripade, kdo chce systemd ten ho ma, kdo ho nechce ten ho nema.

  • 8. 5. 2017 1:49

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    Přiznám se, že nevím, jak je na tom s OpenRC, ale se sysvinitem funguje stále bez problémů a pro Upstart je doporučený nějaký bridge (udevovská pravidla), který vyvolává eventy v Upstartu (spouštění služeb při připojení HW), ale funguje i bez toho.

    Hlavní důvod vzniku Eudev je právě ta podpora jiných toolchainů:
    In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99

  • 6. 5. 2017 21:08

    jednoduchost (neregistrovaný) ---.net.upcbroadband.cz

    Jedná se prostě o směr, kterým se linux v poslední době ubírá.
    Dříve nebylo problém rozumět celému systému a nakonfigurovat ho pomocí textových souborů.
    Teď se stává systém natolik složitý a nepřehledný, že na konfiguraci je potřeba firma (zdravím červený klobouk).
    Pro mne přestává mít smysl jej používat, když mu nerozumím.
    Raději si nainstaluji Windows, vyjde to nastejno.
    Takže ve skutečnosti je systemd jen "vrcholek ledovce".

  • 6. 5. 2017 23:02

    Stefan (neregistrovaný) ---.tmcz.cz

    Linux používám někdy od RedHat 4.0 později na desktopu Fedora a servery Centos nebo RHEL a popravdě konfigurace kromě změny initu se nezměnila takřka vůbec. Všechny konfigurační soubory jsou stále textové a okomentované a zdokumentované.

  • 7. 5. 2017 1:46

    unbelievable (neregistrovaný) 85.17.24.---

    To, že někdo vyvíjí a udržuje distro s takovou odpornou zrůdností, jako jsou init skripty (do nebe volající, nespravovatelná sračka, co nemá, nikdy neměla ani nebude mít na Linuxu co dělat), mně jen utvrzuje v přesvědčení o správnosti použití libovolné - ale jiné - alternativy. Budiž jí klidně a rád i systemd.

  • 7. 5. 2017 4:25

    v.sp (neregistrovaný) 202.89.130.---

    Přidám jeden důvod, proč nemám rád systemd: musí běžet, aby šly spouštět servicy. Initd běžet nemusí, skript servicu spustí i tak. A aby systemd milostivě běžel, tak musí mít dbus či jak se to jmenuje.
    No a to všechno znamená, že je naprosto nepoužitelný v dockeru. Ten dbus tomu kontejneru nedá, systemd se spustit nedá a service se nespustí.
    Já vím, že spouštět servicy není "správně dockerovské", ale při vývoji či prototypovaní je příjemné, když můžu nějak jednoduše spustit sshd či nějakou databázi a nemusím u toho hned studovat všechny parametry a konfiguraci.

  • 7. 5. 2017 9:24

    Filip Jirsák

    Systemd v Dockeru může běžet. A výhoda systemd je mimo jiné v tom, že spouští služby stejně, jako je spouštíte z příkazové řádky. Takže nepotřebujete spouštět žádné skripty – prostě si jen zkopírujte ten příkaz, který je uvedený v unit souboru, a spusťte jej.

  • 7. 5. 2017 12:32

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    Zkuste si ten neběžící init sestřelit ;)

    systemd se nejen dá používat s Dockerem, třeba CoreOS ani jinak nefunguje.

  • 7. 5. 2017 11:19

    zero (neregistrovaný) ---.eurotel.cz

    Je mi vývojářů devuanu skoro až líto, roky se s tím pachtěj, ale stejně to pořádně nefunguje a bude hůř. Perspektiva podobných truc forků žádná, jednoho dne to zabalí úplně, tak jak to nedávno dopadlo s unity a mir.

  • 7. 5. 2017 12:36

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    Jestli nebude problém v tom, že kecalů, co nechtějí systemd, je spousta, ale že by přiložili ruce nebo peníze k dílu, to už ne.

  • 7. 5. 2017 20:58

    Petr (neregistrovaný) ---.signal.center

    ... anebo těm forkům prostě lidi nevěří, osobně bych tomu taky nevěnoval ani minutu. Ani testování, natož reportování. Vznik forku, pro mě, rovná se mrtvý projekt. U opensource projektů je děsivý nedostatek vývojářů, k čemu upstream ještě víc oslabovat?!

  • 7. 5. 2017 21:07

    Ondra Satai Nekola

    Na tom bude kus pravdy, ale obcas se preci jenom forkum zadari (Libre Office jasne valcuje OO a trebas neovim minimalne vyrazne ovlivnuje budoucnost vimu). Na druhou stranu tohle opravdu vypada jako zbytecny trucpodnik bez valne podpory.

  • 8. 5. 2017 15:28

    Thorn (neregistrovaný) 87.244.233.---

    Ďalší keco, čo si to neskúsil.
    Mám devuan nainštalovaný na niekoľkých pc a idú spoľahlivo, odkedy som na nich odišiel z debianu na devuan.
    Ešteže sa nájdu takí, čo sa im chce premýšľať ako újsť z toho systemd pekla.
    Možno raz bude systemd stabilné, použiteľné, ale to už asi bude snežiť v lete.

  • 8. 5. 2017 20:12

    KL (neregistrovaný) ---.antik.sk

    Co ty s tym unixom vlastne stvaras ked tvrdis take nezmysly ako ze systemd je peklo. Nezaspal si dobu? Init bol fasa tak pred 10 rokmi, odvtedy kernel aj distra znacne narastli a peklom sa minimalne pre maintainerov stal prave ten spagetovy init. My sme zmigrovali na systemd asi pred rokom a odvtedy mam klud a nudim sa a skrabem si gule. Ked to porovnam s foframi spred 3 rokov ked som neraz chodil domov o polnoci koli problemom s updatmi a bordelom v init scriptoch tak vas Devuanistov mozem len sucitne lutovat. Ved vas to prejde ked maintaineri zacnu po prvych problemoch z toho distra utekat kade lahsie..

  • 8. 5. 2017 0:00

    Petr (neregistrovaný) ---.cable.dynamic.surfer.at

    Vypada to dost desive..