Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: jeniceek 17. 05. 2016, 15:20:11
-
Ahoj, zkoumal jsem rozdíly mezi systemd a initem a zdá se mi že systemd je postatně lepší, modernější a bezpečnější řešení. Proč jsou všichni správci proti systemd? Většinou totiž řeší všechno, na co si kdy stěžují. Podle mně jsou prostě líní učit se něco nového. Co vy na to?
-
Přečti si diskusi k http://www.root.cz/zpravicky/devuan-jessie-debian-bez-systemd-v-prvni-betaverzi/
-
Ja nejsem proti, me systemy ho nemaji (openbsd). Vlastne jsem ho nikdy ani poradne nevidel. a to je uz na svete dlouho.
-
...dodal bych k té diskusi jenom jedno:
Proč jsou všichni správci proti systemd? Většinou totiž řeší všechno, na co si kdy stěžují.
Admini oceňují především stabilitu. S klasickými init systémy se naučili pracovat, znají jejich vlastnosti (dobré i špatné), nemusí se bát, že jim podrazí nohy v nejmíň vhodnou chvíli, umí hodně dobře předvídat jejich chování a umí je v případě chyby rychle opravit.
Systemd je natolik nové a živé, že admini mají (podle mě oprávněný) strach z nepředvídatelnosti. Navíc systemd adminům přináší jenom málo, pro servery má jenom málo killer features, jestli vůbec nějaké. Největší plus je asi potenciálně lepší integrovatelnost s kontejnery. Druhé plus může být automatické restartování služeb, ale na to už nástroje existují i pro klasické inity (supervisord, daemontools apod.)
Takže typický nespokojenec je admin, typický spokojenec uživatel desktopu (typicky jenom proto, že mu to božsky rychle bootuje ;) )
-
typický spokojenec uživatel desktopu (typicky jenom proto, že mu to božsky rychle bootuje ;) )
na to mam SSD a ne nejaky programy...
-
na to mam SSD a ne nejaky programy...
A když máš SSD i systemd, tak ti to místo pěti sekund bootuje čtyři, což je přímo orgiastický zážitek :)))
-
typický spokojenec uživatel desktopu (typicky jenom proto, že mu to božsky rychle bootuje ;) )
na to mam SSD a ne nejaky programy...
SSD je jedna cast reseni. Init musi byt druha - predstav si, ze mas init, ktery spousti veci jednu za druhou a jedna z tech veci trrrrrvaaaaa (trebas protoze se pokousi o neco na siti...)
(Tim nerikam, ze jak to resi systemd je jedine mozne reseni toho problemu. Jen ze SSD samotne nestaci a nevhodny SW ti muze zpusobit pomale bootovani i na rychlem HW)
-
Pak je asi potreba definovat hranici mezi rychlym a pomalym bootem. Mozna mam jen stesti na to ze nepotkavam "spatne" programy a vidim proste jediny realny rozdil v rychlosti bootovani HDD vs SSD (u widli samozrejme taky cisty system vs nejakou dobu pouzivany system)
-
Proti nejsou všichni správci – naopak podle rychlosti šíření systemd se dá soudit, že proti je jen menšina.
Důvody, proč jsou v internetových diskusích často vidět komentáře proti systemd jsou: nadávat na systemd je módní, konzervatismus správců, technické důvody (chyby v kódu apod.) a jiné. Poměr mezi těmi důvody bych viděl klasicky na 90 % : 9 % : 0,9 %.
-
Důvody, proč jsou v internetových diskusích často vidět komentáře proti systemd jsou
To je jenom "zbozne" prani, doklady pro to zadne nemas.
-
Ale ta rychlost bootu je dnes fakt úžasná killer feature! Koukám na up-time svého nouťase, ze kterého píšu, a vidím tu 77 dnů. No uznejte - když mi systém naběhne o 5 s dřív! To ušetřím 5 s života každé 2 měsíce! A kvůli tomu se už rozhodně vyplatí totálně rozes...t, co 40 let fungovalo.
Systemd je špatný už kvůli tomu, že jde proti základní myšlence unixů - spousta malých utilitek a skriptů dělajících dobře pokud možno jednu věc, jež je možné různě spolu kombinovat, provazovat a přesměrovávat jejich - pokud je to možné - textové vstupy a výstupy. Systemd tohle všechno popírá od A do Z. Jedna velká splácanina, binární logy, autoři se zřejmě řídili i heslem "co oči nevidí, to srdce nebolí"...
-
http://0pointer.de/blog/projects/the-biggest-myths.html
-
http://0pointer.de/blog/projects/the-biggest-myths.html
To jen dokazuje, že to jsou opravdu diletanti, kteří vůbec nic nepochopili a mají se ještě hodně co učit. Já furt říkám, že ještě horší než blbec je polovzdělanec.
-
http://0pointer.de/blog/projects/the-biggest-myths.html
To jen dokazuje, že to jsou opravdu diletanti, kteří vůbec nic nepochopili a mají se ještě hodně co učit. Já furt říkám, že ještě horší než blbec je polovzdělanec.
Jako kdyz nekdo tvrdi, ze je to kvuli rychlosti a ono neni? ;)
-
Jako kdyz nekdo tvrdi, ze je to kvuli rychlosti a ono neni? ;)
Jestli narazis na me, tak ja jsem nerikal, ze je to KVULI rychlosti, ale ze rychlost bootu je vec, kterou typicky lidi ocenuji. Protoze zadne jine dusledky to (zatim?) pro BUD (Bezneho Uzivatele Desktopu) nema.
-
Jako kdyz nekdo tvrdi, ze je to kvuli rychlosti a ono neni? ;)
Jestli narazis na me, tak ja jsem nerikal, ze je to KVULI rychlosti, ale ze rychlost bootu je vec, kterou typicky lidi ocenuji. Protoze zadne jine dusledky to (zatim?) pro BUD (Bezneho Uzivatele Desktopu) nema.
Ne, tys to napsal dobre. Spis narazim na vetsinu kritiky na SystemD, ktera vetsinou necetla ani FAQ. (Cimz nerikam, ze neni i zajimava kritika)
-
http://0pointer.de/blog/projects/the-biggest-myths.html
To jen dokazuje, že to jsou opravdu diletanti, kteří vůbec nic nepochopili a mají se ještě hodně co učit. Já furt říkám, že ještě horší než blbec je polovzdělanec.
Jako kdyz nekdo tvrdi, ze je to kvuli rychlosti a ono neni? ;)
As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
For a fast and efficient boot-up two things are crucial:
* To start less.
* And to start more in parallel.
zdroj: http://0pointer.de/blog/projects/systemd.html
Takže jak? Je nebo není? Přejete-li si slyšet, že je, tak je. Přejete-li si slyšet, že ne, tak není. Tak nějak?
Mimochodem to, co tu cituji, jen dokládá, že ten člověk je v oblasti návrhu OS naprostý diletant. Kdyby kdy v životě sáhl po nějaké odborné literatuře a pročetl se alespoň k závěru úvodní kapitoly, tak by se tam naopak dozvěděl, že není pravda, že zavádění OS musí být kdo ví jak vyladěné co do rychlosti a elegance návrhu. Důvod je prostý: zavádění tvoří jen nepatrný zlomek času běhu OS. OS musí být navržen tak, aby byl efektivní a elegantní při běhu. Ne při zavádění. Protože jde o protichůdné požadavky - elegance zavádění bude vykoupena různými nešikovnostmi, jež se budou projevovat za běhu, což je mnohem horší, než kdyby tomu bylo naopak.
Další kravina jako dům je "And to start more in parallel". NE!!! Zavádění OS je příliš nízkoúrovňová a pro spolehlivost celého OS kritická záležitost na to, aby se při tom vyváděly takovéto vylomeniny jen pro to, že to jde, a jejich autor ve své nezměrné omezenosti si není schopen představit, jaké problémy a nedeterminističnosti to může způsobit.
-
Nenos drivi do lesa, tady uz vetsina lidi Poetteringa povazuje za debila.
-
"Proč jsou všichni proti systemd?"
Protože proti němu zdaeka všichni nejsou. Je hloupé si něco takového myslet a neni žádný reálný důvod pro tot tvrzení.
Systemd byl uveden, prosadil se, používá se a tím to končí ať se to někomu líbí nebo ne.
-
Všichni určitě nejsou. Kdyby ano, neprosadí se.
To že je víc slyšet nadávek je jasný, je to takhle všude. Když ti něco nejede, nevyhovuje, spíš si najdeš čas vylejt si srdíčko, než když nemáš problém.
Můj osobní postoj je ten, že je jedině dobře že něco vystřídá (vystřídalo) init scripty, jistě fungují, ale jeden člověk si to upatlá takhle, druhej zase tak, nutnost supervisora pro kontrolu běhu apliakce... Unit file je o proti tomu nadhera (za idealních podmínek), přehledně si tam potřebné nastavíš a funguje.
Jenže největší problém je ten, že systemd pohlcuje i věci okolo a zdá se že nic nedělá pořádně. V tomhle stavu jakém to je, je to spíš open beta.
-
...dodal bych k té diskusi jenom jedno:
Proč jsou všichni správci proti systemd? Většinou totiž řeší všechno, na co si kdy stěžují.
Admini oceňují především stabilitu. S klasickými init systémy se naučili pracovat, znají jejich vlastnosti (dobré i špatné), nemusí se bát, že jim podrazí nohy v nejmíň vhodnou chvíli, umí hodně dobře předvídat jejich chování a umí je v případě chyby rychle opravit.
Systemd je natolik nové a živé, že admini mají (podle mě oprávněný) strach z nepředvídatelnosti. Navíc systemd adminům přináší jenom málo, pro servery má jenom málo killer features, jestli vůbec nějaké. Největší plus je asi potenciálně lepší integrovatelnost s kontejnery. Druhé plus může být automatické restartování služeb, ale na to už nástroje existují i pro klasické inity (supervisord, daemontools apod.)
Takže typický nespokojenec je admin, typický spokojenec uživatel desktopu (typicky jenom proto, že mu to božsky rychle bootuje ;) )
lidi s desktopem by to nemeli resit, protoze uspavaji :)
vlastne ta viditelnejsi (a mene vyznamna) vlastnost systemd - rychly boot - moc lidi netrapi (adminy vubec, ostatne treba IBM zelezo si klidne startuje pul hodiny a co jako) a pro desktop je lepsi se zamyslet, proc/kdy nefunguje uspavani.
-
Ja nevim, co furt resite, jak rychle to bootuje. Na Atomu to bez systemd zabere mozna 2 minuty a to jeste do znacne miry vinou mechanickeho IDE disku. Pochybuji, ze by to systemd nejak vytrhl, spis bych podeziral opak, kdyz se tam bude deset programu pretahovat o hlavy.
-
Ja nevim, co furt resite, jak rychle to bootuje. Na Atomu to bez systemd zabere mozna 2 minuty a to jeste do znacne miry vinou mechanickeho IDE disku. Pochybuji, ze by to systemd nejak vytrhl, spis bych podeziral opak, kdyz se tam bude deset programu pretahovat o hlavy.
A viděl jste někdy aktuální hardware s mnohajádrovým CPU a rychlým SSD?
-
A viděl jste někdy aktuální hardware s mnohajádrovým CPU a rychlým SSD?
Mně pracovní stanice s postarším, ale slušným šestijádrovým Xeonen startuje víc než minutu...
...a je mi to úplně jedno, zapnu si ji přes WOL pět minut před tím, než jdu pracovat :)
-
A viděl jste někdy aktuální hardware s mnohajádrovým CPU a rychlým SSD?
Mně pracovní stanice s postarším, ale slušným šestijádrovým Xeonen startuje víc než minutu...
...a je mi to úplně jedno, zapnu si ji přes WOL pět minut před tím, než jdu pracovat :)
To zní jako do značné míry debilní BIOS nebo extrémně pomalý HDD. S tím ale systemd nic nenadělá...
-
Ze im na to este skocite. Mna uz to celkom unavuje.
Zacina to vzdy rovnako, nejaky zlesasavynorivsi "diskuter" polozi zdanlivo nevinnu otazku "Nechapem, co vsetci maju proti s.....d, mne to bezi uplne bez problemov"... a potom nasleduje zaplava prispevkov s argumentami, preco je shitstemd cele zle, a k tomu z opacneho tabora zaplava opakujucich sa prispevkov, ako su vsetci admini lenivi sa ucit nove veci...
Cele je to ako cez kopirak, clovek sa z takej diskusie nic nove nedozvie...
Neviem, ci je za tym nejaky propagacny zamer shitstemd uderky, alebo je to len klasicky trolling, kedy trol polozi zamerne provokativnu otazku (vyzerajucu zdanlivo nevinne) a potom sa vytesuje na tom, ako vsetci zapalisto diskutuju (svojho casu sa tak zabaval Michal Kolesa). V kazdom pripade, zabity cas...
-
Ja nevim, co furt resite, jak rychle to bootuje. Na Atomu to bez systemd zabere mozna 2 minuty a to jeste do znacne miry vinou mechanickeho IDE disku. Pochybuji, ze by to systemd nejak vytrhl, spis bych podeziral opak, kdyz se tam bude deset programu pretahovat o hlavy.
A viděl jste někdy aktuální hardware s mnohajádrovým CPU a rychlým SSD?
Jo, ale byly na tom Widle. Ale nevim, na co by mi na takovem HW byly systemd. Uspora dalsich 3 vterin? Ono je pravda, ze ty tri vteriny muzou byt dulezite. Dnesni clovek ma pry attention span 7 vterin, coz je o nekolik vterin mene, nez ma zlata rybka. Takze by se kvuli trem vterinam mohlo stat, ze zapomene, ze si zapnul pocitac a chtel na nem neco delat.
-
Ale ta rychlost bootu je dnes fakt úžasná killer feature! Koukám na up-time svého nouťase, ze kterého píšu, a vidím tu 77 dnů. No uznejte - když mi systém naběhne o 5 s dřív! To ušetřím 5 s života každé 2 měsíce! A kvůli tomu se už rozhodně vyplatí totálně rozes...t, co 40 let fungovalo.
Systemd je špatný už kvůli tomu, že jde proti základní myšlence unixů - spousta malých utilitek a skriptů dělajících dobře pokud možno jednu věc, jež je možné různě spolu kombinovat, provazovat a přesměrovávat jejich - pokud je to možné - textové vstupy a výstupy. Systemd tohle všechno popírá od A do Z. Jedna velká splácanina, binární logy, autoři se zřejmě řídili i heslem "co oči nevidí, to srdce nebolí"...
To, ze neco fungovalo 40 let, neznamena, ze to splnuje pozadavky i po 40 letech. A tech hacku a obchcavek, aby se obesly omezeni initu...
A co se tyce unixu, linux != unix, to za prve, a za druhe, ne kazdy zije ve svete textovych vstupu a vystupu a za treti, lepeni xx utilitek, aby z toho vznikl vetsi projekt je mnohdy fakt uzasna vec, nejen z hlediska vykonu/spravy takoveho reseni.
-
"propagacny zamer shitstemd uderky, alebo je to len klasicky trolling" - clovek co pise shitstemd ide komentovat trolling...
-
na to mam SSD a ne nejaky programy...
A když máš SSD i systemd, tak ti to místo pěti sekund bootuje čtyři, což je přímo orgiastický zážitek :)))
Me to bootuje 3 a bez systemd ... nehelde na to, ze na serverovym zeleze trva 15+ minut jen post, takze me boot systemu nezajima naprosto vubec. A zminovanej restart servisu je naopak neco naprosto neakceptovatelnyho, protoze kdyz neco padne, tak to ma nejakej duvod a znova to bez vyreseni toho duvodu nastartovat = zmrvit treba data.
Proti nejsou všichni správci – naopak podle rychlosti šíření systemd se dá soudit, že proti je jen menšina...
Dybys nezvani Jisak, zase tvoje davka sracek? Zadnej admin si tenhle binarni blob na svy stroje nepusti jeste hodne dlouho pokud vubec nekdy.
ad paralelni start - je opravdu zuzo resit, co a proc se podelalo, kdyz to startuje jedno pres druhy, a podle toho to taky loguje. I kdyz systemd to vyresil, to je fakt, jestli se neco podela zcela jiste, tak ten binarni log, takze vlasne nic nezaloguje a tim je problem vyresen.
...
To, ze neco fungovalo 40 let, neznamena, ze to splnuje pozadavky i po 40 letech. A tech hacku a obchcavek, aby se obesly omezeni initu...
Tak jasne, kdyz ti neco nebude fungovat na systemd, tak ses proste v pici, protoze zadnou vochcavku neudelas. Debil Poettering to prohlasi za vlastnost. Pokud potrebujes nejaky vlastnosti logovani tak ses taky v pici, protoze zadnej jinej logger si nevyberes. Pokud chces mit stroj zabezpecenej tak ses v riti 10x, protoze tohle nastartuje sit driv, nez kernel ... kdyz chces stopnout demona, tak ho proste nestopnes, protoze ti to podrukama znova nastartuje. Kdyz ho chces nastartovat, tak prozmenu zustane chciplej ... protoze je prece uzasny, aby webserver startoval 50x denne on demand ... user si tech 5 minut pocka.
-
Tak jasne, kdyz ti neco nebude fungovat na systemd, tak ses proste v pici, protoze zadnou vochcavku neudelas. Debil Poettering to prohlasi za vlastnost. Pokud potrebujes nejaky vlastnosti logovani tak ses taky v pici, protoze zadnej jinej logger si nevyberes. Pokud chces mit stroj zabezpecenej tak ses v riti 10x, protoze tohle nastartuje sit driv, nez kernel ... kdyz chces stopnout demona, tak ho proste nestopnes, protoze ti to podrukama znova nastartuje. Kdyz ho chces nastartovat, tak prozmenu zustane chciplej ... protoze je prece uzasny, aby webserver startoval 50x denne on demand ... user si tech 5 minut pocka.
Pri systemd lze pouzit i jiny logger.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-interaction_of_rsyslog_and_journal.html
Journald zkratka vystavi messages v Syslog formatu RFC5424 na UNIX socketu, odkud si je RSyslog dale bere ke zpracovani.
Autorestart services je default trebas na Solarisu, tam se servica enabluje/disabluje pokud pada prilis casto, skonci v maintenance modu. A nejak mi tento zpusob prace se services nedela problemy, je to jine, rozhodne ne horsi.
Ve vysledku je to stejne debata o hovne, protoze kazdy admin, co neni totalni matlak, stejne preposila logy na centralni RSyslog, nebo centralni Logstash s Elasticsearch ulozistem a Kibanou na cumeni.
Beh services hlida nejakym Zabbixem a konfiguruje centralnim Puppetem.
Takze je v dusledku lautr jedno, jestli je na serveru initd nebo systemd.
-
Proti nejsou všichni správci – naopak podle rychlosti šíření systemd se dá soudit, že proti je jen menšina.
Důvody, proč jsou v internetových diskusích často vidět komentáře proti systemd jsou: nadávat na systemd je módní, konzervatismus správců, technické důvody (chyby v kódu apod.) a jiné. Poměr mezi těmi důvody bych viděl klasicky na 90 % : 9 % : 0,9 %.
Čekal jsem, kdy a od koho se tu objeví podobné moudro. Můj tip byl buď Nový nebo Jirsák. A nemýlil jsem se.. :)
"Proti nejsou všichni správci – naopak podle rychlosti šíření systemd se dá soudit, že proti je jen menšina." - Aha, takže ono to závisí vždy a pouze na těch správcích, jestli se bude používat SysD či nikoliv.
Ono záleží na firmě. Pokud firma jede stabilně na nějakém konkrétním distru a to distro (resp. jeho vývojáři) se rozhodne přejít na SysD, tak co má admin dělat, pokud firma pravidelně updatuje na nejnovější verze? Možná by to mohl překopat na vlastní odpovědnost, ale k tomu jeho nadřízení nemusí mít pochopení, stejně tak by pro to nemusel mít pochopení oficiální support dodavatele systému, takže záleží asi spíš na firmě jestli mu dá volnou ruku či nikoliv.
-
Takze je v dusledku lautr jedno, jestli je na serveru initd nebo systemd.
Pokud je někde situace taková jaká píšeš (ne všude je), tak pak systemd už vůbec nic nepřináší, jenom způsobuje riziko a nejistotu. Takže v takové situaci to vůbec jedno není.
-
Tak já, jako "programátor" mám systemd rád. Daemonizace v unixu je prostě tristní a jsem konečně rád, že to prostě nemusím programovat. Žádný double-forky a podobně, řešení čehokoliv - napíšu unit soubor a je to. Super. Problém vyřešen.
Druhá věc je technické provedení - když jsem viděl, jak se autoři staví k řešení některých bugů, tak to je na vyhazov.
V praxi mám pocit, že to funguje. Takže systemd mám rád :)
-
Daemonizace v unixu je prostě tristní a jsem konečně rád, že to prostě nemusím programovat. Žádný double-forky a podobně, řešení čehokoliv - napíšu unit soubor a je to. Super. Problém vyřešen.
Nevím jak v různých distribucích Linuxu, ale ve FreeBSD je https://www.freebsd.org/cgi/man.cgi?query=daemon&sektion=8 který to řeší úplně v pohodě.
Taky se na to dá dívat opačně: všechny serverové aplikace daemon mód už mají, takže opět systemd nic nového nepřináší. Maximálně může ušetřit práci u zbrusu nových serverových aplikací, ale ty se dají úplně v pohodě řešit právě nějakou obdobou daemon(8). Takže opět ta samá otázka: "a stojí to za to?!" ;)
-
Tak já, jako "programátor" mám systemd rád. Daemonizace v unixu je prostě tristní a jsem konečně rád, že to prostě nemusím programovat. Žádný double-forky a podobně, řešení čehokoliv - napíšu unit soubor a je to. Super. Problém vyřešen.
Druhá věc je technické provedení - když jsem viděl, jak se autoři staví k řešení některých bugů, tak to je na vyhazov.
V praxi mám pocit, že to funguje. Takže systemd mám rád :)
Tak pominu to, ze Linux neni Unix. To opravdu kazdy vedet nemusi. Init jsem vzdy sam povazoval za hrozny.
Predpokladam ale, ze veci co jdou resit uplne trivialne jako tady http://man.openbsd.org/OpenBSD-current/man8/rcctl.8 jsou v programatorskych kruzich sproste slovo, protoze k tomu neni dostatek Kool Aid a proste to jen trapne jednoduse funguje :-)
-
pokud si vzpominam spravne, tak hlavni vlna protestu proti systemd byla z toho duvodu, ze:
systemd prodrazuje exponencialne praci spravcu
systemd zlevnuje "cookie cutter" cloudove nasazeni, kde se firma vzda jakychkoliv vlastnich pozadavku na odlisnosti.
-
a to je zobecneni jednotlivych arguemntacnich bodu.
ano systemd je pro firmy kratkodobym prinosem,
protoze manager rozhodne o cloudu a zruseni mista spravce.
dlouhodobe je to vendor lock-in, ktery vyjde extreme draho.
-
Pri systemd lze pouzit i jiny logger.
Nejde, musis tam mit ten jejich a mozna teprve z nej si muzes prebirat cosi do dalsiho demona (coz je uchylny samo o sobe), ale kdyz ti nepojede ta systemd sragora, tak zadny logy nebudou.
A viz dalsi, v dusledku je to o tom, ze kdyz se na systemd neco podela, tak si to admin nespravi, a nespravi to ani kdyby to chtel spravit primo v kodu, protoze to by si pak leda musel celej init udrzovat sam. Podivej se na hlaseni zcela zjevnych chyb a reakce tech idiotu kolem systemd.
-
Nevím jak v různých distribucích Linuxu, ale ve FreeBSD je https://www.freebsd.org/cgi/man.cgi?query=daemon&sektion=8 který to řeší úplně v pohodě.
Součástí std. instalace to není, možná jako nějaký balíček.
Taky se na to dá dívat opačně: všechny serverové aplikace daemon mód už mají, takže opět systemd nic nového nepřináší. Maximálně může ušetřit práci u zbrusu nových serverových aplikací, ale ty se dají úplně v pohodě řešit právě nějakou obdobou daemon(8). Takže opět ta samá otázka: "a stojí to za to?!" ;)
No mě přijde, že ano. Třeba proto, že řešení před PIDfily vypadá dost jako hack. Integrace s cluster-warem funguje v pohodě. Závislosti fungují. Věci je vhodné řešit "systémově" a nikoliv nějakým hackem do init.d. Ale hlavně - tady si pořád všichni stěžují a já jsem fakt nepochopil na co. Journalctl mi ušetřil spoustu času, když jsem hledal, který daemon mi proč nestartuje. Tak na co si tady pořád všichni stěžují? Že to je nové a co je nové je špatné?
Podivej se na hlaseni zcela zjevnych chyb a reakce tech idiotu kolem systemd.
Tohle je argument, se kterým mi nezbývá než souhlasit. Ale to ostatní mi fakt připadá na té úrovni, že XML je špatné, protože prohlížeč při načítání selže, když nezavřete tag.
-
Součástí std. instalace to není, možná jako nějaký balíček.
Ale je (mluvím o FreeBSD):
# which daemon
/usr/sbin/daemon
Třeba proto, že řešení před PIDfily vypadá dost jako hack.
Tak hack, je to prostě určitý druh handlu, čemu konkrétně to vadí? Přijde ti třeba jako hack, že tmux má v /tmp nějaký svůj socket? Nebylo by lepší se na něj připojovat přes DBUS? :)
Integrace s cluster-warem funguje v pohodě. Závislosti fungují. Věci je vhodné řešit "systémově" a nikoliv nějakým hackem do init.d. Ale hlavně - tady si pořád všichni stěžují a já jsem fakt nepochopil na co.
Líbí se ti třeba, jak systémově řeší služby Windows? Co můžeš mít proti? Závislosti fungují, logování taky. Paráda, ne?
Různí lidi si stěžují na různé věci, ale admini nejspíš na to, že jim to nepřinese nic než spoustu práce a nejistoty. Protože se starými inity se už sžili, vychytali si jejich vlastnosti a žádné úplně zásadní nevýhody nemají.
-
P.S.
žádné úplně zásadní nevýhody nemají.
to, že init skripty ve spoustě linuxových distribucí jsou k zblití a často nefungují, to je jiná kapitola. Zprasit jde samozřejmě všechno. Ale taky to jde napsat inteligentně (viz třeba ty init skripty ve FreeBSD - většinou na pár řádků, čistě "deklarativní").
-
Líbí se ti třeba, jak systémově řeší služby Windows? Co můžeš mít proti? Závislosti fungují, logování taky. Paráda, ne?
Já nevím, jak to funguje ve FreebBSD - asi dobře. Pidfily jsou hack, protože to, že to číslo procesu v pidfilu má nějakou relevanci taky je docela náhoda. Ale vůbec nechápu, co je špatného na tom, že
- daemon je normální unixový standardní program, který normálně běží a může klidně logovat na stdout stderr
- zda je ten program živý kontroluje systémový daemon napřímo
- výstupy jsou pěkně tříděny, opatřeny časovou značkou
- konfigurace se provádí deklarativní formou
Různí lidi si stěžují na různé věci, ale admini nejspíš na to, že jim to nepřinese nic než spoustu práce a nejistoty. Protože se starými inity se už sžili, vychytali si jejich vlastnosti a žádné úplně zásadní nevýhody nemají.
Mě to nějak připadá, jako dohadovat se s vývojářem PHP, že přechod na lepší jazyk mu přinese nic než spoustu práce a nejistoty, protože s PHP špagetama už se sžil, vychytal si jejich vlastnosti a žádné úplně zásadní nevýhody nemají.
V průběhu posledních pár let jsem vyprodukoval několik programů, které běžely jako daemon a systemd (a před tím to, co bylo v ubuntu, nevím, jak se to jmenovalo - upstart?) byl první případ, kdy jsem vyrobil konfigurák a ono to fungovalo. Ten princip mě přijde super. A na argumenty typu "tohle umím, proč bych měl přecházet na něco jiného" začínám být trochu alergický.
-
...
Mě to nějak připadá, jako dohadovat se s vývojářem PHP, že přechod na lepší jazyk mu přinese nic než spoustu práce a nejistoty, protože s PHP špagetama už se sžil, vychytal si jejich vlastnosti a žádné úplně zásadní nevýhody nemají.
...
"Hele, ty jsi PHPkař. Víš, jakej je to sprasenej jazyk. Koukej, tady mám lepší. Je funkcionální, všechno naprosto intuitivní, samozřejmě, to, že je to FP, neznamená, že tam jsou monády, neboj. Píšem to tady s klukama už asi půl roku, a už to celkem funguje. Ještě jenom poladíme pár drobností jako právě ty monády, jako aby tam nebyli, ale bylo to pure. No, přepíšeme do toho tady ALZA e-shop, co říkáš?"
-
Se zájmem sleduji tuhle diskuzi...
Osobně si myslím, že v raných verzích byl systemd skvělý. Uměl startovat jednoduše daemony, umožňoval výrazně rychlejší start, nejen díky paralelnímu startu (to uměl i klasický init, např. v Debianu už dávno před tím), ale také díky tomu, že nemusel čekat na start některých daemonů, na kterých záviselo něco jiného, protože např. poskytoval jeho rouru sám a tu mu pak po jeho startu předal, takže věci závislé na něm na jeho start čekat nemusely (typicky dbus). Umělo to zrychlit start 2x i 3x v závislosti na HW. Malý, jednoduchý, dělal co dělat měl. Dal se jednoduše vyměnit za kterýkoli jiný boot init, což je ve světě Linuxu tak běžná a předpokládaná věc.
Pak se to začalo zvrhávat v to, že nabaloval na sebe další věci, které nejsou nutné, binární logy, ke kterým může být problém se dostat, když něco selže (a selhávání není výjimka). Nahrazování systémových částí svými, které nejsou "kompatibilní" a proto už nejde příslušná část vyměnit, pokud se původní zavedená alternativa nepřizpůsobí. Zažírání do částí desktopových software, které pak umějí běžet jen s ním ap. A úplně blbé je, když se vám jedna a ta samá instalace chovala na jiných PC různě - na některých start selhal na druhých ne. Nebo po vypnutí jader CPU a start na jednom se situace "opravila" a systém, který nenastartoval už naběhl. Sám jsem zažil, že po instalaci či upgrade systému příští start už neproběhl. Ať jsem se jako dekádami znalý odborník snažil, nebylo možné přijít na to, kde je chyba. Když jsem se to snažil řešit s maintainery balíčků a vývojáři, selhalo i toto. Museli konstatovat, že neví kde je problém. Nakonec jsem ten konkrétní problém vyřešil, protože jsem přišel na to, že se tam tluče paralelní start systemd a jeho vlastní služba readahead - vypnutím readahead a smazáním jeho cache souborů (vypnout nestačilo!!!) se to umravnilo (a to i přesto, že jsem si pak readahead zase zapnul). Ale bylo to pokus omyl a tenhle způsob mi byl na Windowsech vždy protivný, protože to znamená, že nemám OS pod kontrolou, jak bych jako admin mít měl a z toho slevovat nehodlám. Bohužel takových případů, kdy se to vyřešit nedá je mraky. Třeba na konkrétním HW při použití prelink prostě systém se systemd nenaběhne. Možné kdykoli předvést. Chyba je zjevně v systemd, protože normálně chcípne. Na jiném HW to nevadí, na jiném pro změnu ano. Jediným východiskem byla reinstalace OS, protože ani vrácení binárek prelinkem do původního stavu nepomohlo a tohle nedeterministické chování je prostě fail. I těmto způsobům jsem na Linuxu po předchozím používání pouze Windows odvykl a opravdu si nehodlám na tohle zvykat, to spíš udělám vlastní boot system, který bude schopen systemd nahradit. Takže základní myšlenka se mi líbí, ale její naplňování je od jistých verzí hodně špatně. Předpokládám, že si nikdo si nepřeje systém, který není schopen naběhnout, bez možnosti to řešit, protože init systém má spoustu vad.
Takže tohle vadí mi osobně, přestože ho používám, hlavně proto, že se mu moc vyhnout nedá a potřebuju prostě s ním umět. Učit se nové věci mi nevadí, naopak, děsně mě to baví. Ale co mě nebaví je, když se v principu deterministický stroj chová díky jedné SW komponentě nedeterministicky. Třeba to je to co vadí i jiným, jen to neumějí správně popsat.
-
2ByCzech: Tesat do kamene.
-
Ted je otazka, co s tim. Co stoji takovy najemny vrah? A na kterem crowdfundingovem serveru by to vzali?
-
Ted je otazka, co s tim. Co stoji takovy najemny vrah? A na kterem crowdfundingovem serveru by to vzali?
A koho chceš zabít? Poetteringa? Ten za to přece nemůže.
-
Ted je otazka, co s tim. Co stoji takovy najemny vrah? A na kterem crowdfundingovem serveru by to vzali?
Jednodušší udělat náhradu ;-). A klidně drze forkem poslední malé funkční verze :-D. Nevěřím, že když se to udělá dobře a bude to mít stále ty dvě "killer features", kterými jsou paralelní start a jednoduchý start daemonů, že to v distrech nenahradí za tenhle malý, jednoduchý a prostě funkční. Admini to uvítají, maintaineři balíčků taky, vývojáři, kteří se to snaží flikovat patchema a nebo speciálními balíčky (aka fintami) *-shim ap. taky a ti co se zoufale snaží hlásit chyby, které jsou místo opravy nazvány vlastnostmi jakbysmet.
-
A koho chceš zabít? Poetteringa? Ten za to přece nemůže.
Idealne vsechny. Podle fotek tri z vyvojaru, ktere jsou na Wikipedii, se musi jednat o mutanty.
-
Jednodušší udělat náhradu ;-). A klidně drze forkem poslední malé funkční verze :-D. Nevěřím, že když se to udělá dobře a bude to mít stále ty dvě "killer features", kterými jsou paralelní start a jednoduchý start daemonů, že to v distrech nenahradí za tenhle malý, jednoduchý a prostě funkční. Admini to uvítají, maintaineři balíčků taky, vývojáři, kteří se to snaží flikovat patchema a nebo speciálními balíčky (aka fintami) *-shim ap. taky a ti co se zoufale snaží hlásit chyby, které jsou místo opravy nazvány vlastnostmi jakbysmet.
To je pěkný, konstruktivní řešení (bez ironie). Dal by si odkaz na verzi, kterou považuješ za ideální start pro fork?
-
Jednodušší udělat náhradu ;-). A klidně drze forkem poslední malé funkční verze :-D. Nevěřím, že když se to udělá dobře a bude to mít stále ty dvě "killer features", kterými jsou paralelní start a jednoduchý start daemonů, že to v distrech nenahradí za tenhle malý, jednoduchý a prostě funkční. Admini to uvítají, maintaineři balíčků taky, vývojáři, kteří se to snaží flikovat patchema a nebo speciálními balíčky (aka fintami) *-shim ap. taky a ti co se zoufale snaží hlásit chyby, které jsou místo opravy nazvány vlastnostmi jakbysmet.
To je pěkný, konstruktivní řešení (bez ironie). Dal by si odkaz na verzi, kterou považuješ za ideální start pro fork?
To bych musel dohledat nebo vykoumat, byla to nějaká verze co se používala v backports větvi tuším v Debian Wheezy. Ale nakonec se to zmrvilo i tam, takže by to bylo nutné vykoumat jak říkám.
PS: Nenapadlo mě, že to je ironie. Netrolujeme tady ne?
-
To bych musel dohledat nebo vykoumat, byla to nějaká verze co se používala v backports větvi tuším v Debian Wheezy. Ale nakonec se to zmrvilo i tam, takže by to bylo nutné vykoumat jak říkám.
A nebo to byl spíš už squeeze backports. Dalo by se (a muselo) dohledat nebo zanalyzovat...
-
Se mi zmnožil příspěvek, tak tento jsem naeditoval a můžete jej ignorovat :)
-
PS: Nenapadlo mě, že to je ironie. Netrolujeme tady ne?
Pokud mě se týče, tak ne. Ale to by Troll tvrdil taky :)
-
PS: Nenapadlo mě, že to je ironie. Netrolujeme tady ne?
Pokud mě se týče, tak ne. Ale to by Troll tvrdil taky :)
Já jsem asi naivní, ale nejdříve předpokládám, že to troll není, až následovně, když se to proflákne ho jako trolla označím a podle toho jednám ;-)
-
PS: Nenapadlo mě, že to je ironie. Netrolujeme tady ne?
Pokud mě se týče, tak ne. Ale to by Troll tvrdil taky :)
Já jsem asi naivní, ale nejdříve předpokládám, že to troll není, až následovně, když se to proflákne ho jako trolla označím a podle toho jednám ;-)
To máš buřt. Ale ten nápad s tím forkem se mi líbí. Zajímalo by mě, zda by se našli lidi, kteří by to podpořili.
-
PS: Nenapadlo mě, že to je ironie. Netrolujeme tady ne?
Pokud mě se týče, tak ne. Ale to by Troll tvrdil taky :)
Já jsem asi naivní, ale nejdříve předpokládám, že to troll není, až následovně, když se to proflákne ho jako trolla označím a podle toho jednám ;-)
To máš buřt. Ale ten nápad s tím forkem se mi líbí. Zajímalo by mě, zda by se našli lidi, kteří by to podpořili.
Mě docela taky a docela rád bych do toho šel... Program s PID 1 by měl být prostě kvalitnější.
-
...
Systemd NEUMI zjistit zda demon zije, tak maximalne jestli je ve stavu "tvarici se zive". Pokud nekdo potrebuje vazne udrzet neco nazivu, tak si stejne musi spustit externi tool, kterej to bude realne testovat.
V gentoo si konfiguraci napisu od conf.d, startovaci script je v init.d a je prevazne tak na 10-20 radku, a pokud nefunguje, tak si tam muzu vrazit normalne svuj bastl. Logdemnona si muzu vybrat z asi 30 variant, stejne jako hromadu dalsich soucasti. Nestartuje mi to dhcpserver, protoze to nanic nepotrebuju, nestartuje mi to sit driv, nez firewall ... a kdyz neco stopnu, tak to je stoply.
Taky se mi do toho nesere dbus, udev a hromada dalsi veci, ktery pouzivat MUZU, ale NEMUSIM.
A viz ByCzech. Sranda je, kdyz dodavatel da req na verzi distra se systemd, a pak se sam divi, jak se to chova. V tomhle pripade ze nahodi svoji appku, ale protoze default "jen" stopnul a disabloval, tak mu pri pristim restartu ta jeho nenabehne, protoze se nejakym rizenim osudu spusti ta default ... takze jediny realny reseni je tu default odinstalovat. Nice ...
To máš buřt. Ale ten nápad s tím forkem se mi líbí. Zajímalo by mě, zda by se našli lidi, kteří by to podpořili.
... proc vymejslet kolo?? Viz gentoo.
Problem spociva jinde, protoze ti kreteni pozrali treba udev. Gentoo si dela eudev.
-
Já nevím, jak to funguje ve FreebBSD - asi dobře.
Takový typický startskript vypadá takhle:
https://github.com/freebsd/freebsd-ports/blob/master/sysutils/rsyslog8/files/rsyslogd.in
- obsahuje jenom deklarace, všechny výkonné části jsou v shellové "knihovně" - společné všem službám.
Že chceš službu startovat při startu OS řekneš tím, že do /etc/rc.conf přidáš jeden řádek:
rsyslogd_enable="YES"
Pokud bys chtěl třeba umístit někam jinam pidfile, přidáš druhý:
rsyslogd_pidfile="/neco/nekde/rsyslogd.pid"
Stejným stylem si může každá služba definovat svoje vlastní optiony, takže třeba do /etc/rc.conf dáš:
slapd_sockets="/neco/nekde/slapd_socket"
Pořadí spouštění to umí (to jsou ty značky PROVIDE, REQUIRE, BEFORE). Supervidovat služby to neumí (pokud to u některé služby chci, používám supervisord).
Samozřejmě některé služby vyžadují trochu speciální zacházení, takže tam se pak nadefinují vlastní start/stop funkce:
https://github.com/freebsd/freebsd-ports/blob/master/www/nginx/files/nginx.in
Pokud se ta služba chová potřebným způsobem (neforkuje apod.), je to naprosto bezproblémové a rock-solid. Jediné služby, kde jsem zaznamenal větší problémy, jsou erlangové, protože ty při start a stop dělají různé psí kusy a občas funguje blbě restart. Vím to, proto místo restartu dělám start stop, problem solved :)
Pidfily jsou hack, protože to, že to číslo procesu v pidfilu má nějakou relevanci taky je docela náhoda.
Nevím, jaká by v tom měla být náhoda. Klasické inity prostě po službách požadují, aby se daemonizovaly a zachovaly pid. Pokud se daemonizovat neumí, použije se jako obálka ten zmíněný daemon( 8 ).
Ale vůbec nechápu, co je špatného na tom, že
- daemon je normální unixový standardní program, který normálně běží a může klidně logovat na stdout stderr
- zda je ten program živý kontroluje systémový daemon napřímo
- výstupy jsou pěkně tříděny, opatřeny časovou značkou
- konfigurace se provádí deklarativní formou
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Ještě drobná poznámka k
a může klidně logovat na stdout stderr
Tobě jako programátorovi to možná přijde jako super nápad, ale je to jedna z nejhorších věcí, co se dá s logováním udělat. Std{out|err} je totiž stream. A do logu potřebuješ dostat záznamy. Takže musíš do toho stdxxx emitovat nějaký strukturovaný formát, který jde na záznamy rozdělit (nejstupidnější řešení je rozdělit ho pomocí \n). Jaké strukturované formáty umí systemd po stdxxx přijímat? Co když budu chtít použít jiný? Tohle já třeba nevím. A musel bych to studovat, zatímco u současných řešení už to mám nastudované a vyřešené. A tohle je přesně ono - pro adminy je to regres - abys dosáhl funkcionality, kterou máš už teď, musíš znovu investovat práci a ladění a i tak budeš žít v nejistotě, jak se to zachová v situacích, které jsi neotestoval. A tohle všechno, aby ses dostal do stavu stejného (ne lepšího) než jsi měl předtím.
Mě to nějak připadá, jako dohadovat se s vývojářem PHP, že přechod na lepší jazyk mu přinese nic než spoustu práce a nejistoty, protože s PHP špagetama už se sžil, vychytal si jejich vlastnosti a žádné úplně zásadní nevýhody nemají. [...] A na argumenty typu "tohle umím, proč bych měl přecházet na něco jiného" začínám být trochu alergický.
Admini jsou přirozeně konzervativní. Každá změna je ohrožení stability. I pokud je to změna vyloženě k lepšímu, pořád je to pro admina nepříjemné. A pokud je to změna, která nic nepřináší, ale zároveň je vysoce riziková, je to prostě enormní osina v ...
Srovnání s PHP je mimo, protože tam předpokládáš vysoký kvalitativní skok (druhý jazyk je třeba daleko produktivnější). To při téhle změně prostě neplatí. Z hlediska admina je to změna pro změnu "aby to bylo čistější".
-
Prepísat do Haskella.
Alebo do iného hentého s. funkcionára.
-
Prepísat do Haskella.
Alebo do iného hentého s. funkcionára.
To už existuje: https://www.gnu.org/software/shepherd/ :)
-
Takový typický startskript vypadá takhle:
Já si nemůžu pomoct, ale mně to pořád připadá jak lépe organizovaný nepořádek...
Nevím, jaká by v tom měla být náhoda. Klasické inity prostě po službách požadují, aby se daemonizovaly a zachovaly pid. Pokud se daemonizovat neumí, použije se jako obálka ten zmíněný daemon( 8 ).
Když ti daemon spadne a přeroluje se ti pid. Možná ten pidfile má být jěště locknutý? Nevím, moc netuším, proč vůbec mít pidfile.
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" a druhý "systemd je blbě napsaný software se spoustou bugů a neschopnýma (nebo všeho schopnýma) vývojářema". S druhým argumentem souhlasím, ale ten první nechápu. Pořád.
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Tobě jako programátorovi to možná přijde jako super nápad, ale je to jedna z nejhorších věcí, co se dá s logováním udělat. Std{out|err} je totiž stream. A do logu potřebuješ dostat záznamy. Takže musíš do toho stdxxx emitovat nějaký strukturovaný formát, který jde na záznamy rozdělit (nejstupidnější řešení je rozdělit ho pomocí \n). Jaké strukturované formáty umí systemd po stdxxx přijímat? Co když budu chtít použít jiný? Tohle já třeba nevím.
Tak ono taky záleží na tom, co chceš logovat. Nevím, co je stupidního na tom dělit to pomocí \n, když víš, že v té zprávě ten enter nebude. Můžeš si to klidně tisknout v jsonu a pak si to někde v log managementu naparsovat. Popravdě syslog zas tak špatný není, máš tam severitu a to je vlastně asi nejdůležitější. Ale ono je typické takové to "jsem na tomhle systému, z nějakého důvodu mi neběží X, co se stalo". A pokud to něco vypsalo, přes journalctl to snadno najdeš.
Srovnání s PHP je mimo, protože tam předpokládáš vysoký kvalitativní skok (druhý jazyk je třeba daleko produktivnější). To při téhle změně prostě neplatí. Z hlediska admina je to změna pro změnu "aby to bylo čistější".
Pokud to myslíš z důvodu kvality provedení systemd, tak to nerozporuji. Pokud tím myslíš z důvodu věcí, které systemd přináší, tak teda nesouhlasím, pro mě to teda výrazný krok dopředu je.
-
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" ... ale ten první nechápu. Pořád.
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Tak to zkus otočit. Když admin spustí nějakou službu, a ona se nechová jak potřebuje, tak jak to fixne? Správně je samozřejmě upravit ty deklarativní unit soubory. To je ok. Ale co když, chudák, narazí zrovna na bug v init systému? On to potřebuje vyřešit. Hrábnutí do scriptů je sice prasečina největší, ale je to řešení. Službu nahodí, a pak začne řešit, co s tím. Dělat to naopak je děs.
-
Já si nemůžu pomoct, ale mně to pořád připadá jak lépe organizovaný nepořádek...
Proč nepořádek? Deklarativní popis služby je jenom nastavení nějakých proměnných. U systemd je to v nějakém .ini formátu, u toho, co jsem ti ukázal, je to v shellovém formátu var=val. V čem ti přijde tak zásadní zlepšení shell->.ini? Mně to přijde jako spíš zhoršení, protože v shell formátu si může - pokud budu chtít - načíst hodnoty libovolným spuštěním příkazu. Třeba wgetem z konfiguračního serveru. U systemd to neuděláš. A kdyby to lidi chtěli, tak se zavede další proměnná "ReadConfigFromHttp", pak se zjistí, že k načítání přes HTTP potřebuješ http knihovnu, tak se http knihovna vloží do binárky PID 1 a následujících deset let se v ní budou nacházet bezpečnostní chyby, umožňující eskalaci na roota. Ale hlavně, že to není nepořádek ;)
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" a druhý "systemd je blbě napsaný software se spoustou bugů a neschopnýma (nebo všeho schopnýma) vývojářema". S druhým argumentem souhlasím, ale ten první nechápu. Pořád.
Jenže ten první argument zní spíš "proč vrtat do něčeho, co funguje?" - každý admin se na změnu dívá stylem "máme silný argument, proč změnu dělat?" a ne "Máme silný argument, proč změnu NEdělat?"
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Ale blbost. Buď je ta oprava triviální, nebo si třeba uděláš jiný startup skript bokem. Kařdopádně oboje děláš nějaký configuration managementem (puppet, ansible, salt...), takže je to změna jako každá jiná.
Konkrétní příklad: triviální chyba ve startup skriptu služby v Ubuntu. Ticket bez opravy visí v bugzille rok: https://plus.google.com/+MiroslavPrymek/posts/TAYTy8DHMLq Co myslíš, že má admin udělat? Opravit to a mít stabilní server, nebo rok čekat, až se někdo v Canonicallu rozhoupe?
Tak ono taky záleží na tom, co chceš logovat. Nevím, co je stupidního na tom dělit to pomocí \n, když víš, že v té zprávě ten enter nebude.
Jenže to nikdy nevíš. Logované zprávy typicky citují nějaká vstupní data, kde se \n může objevit i když to nečekáš. A celej logging se ti takovou blbostí může rozesrat. Spolíhat na to, že se ti nikdy v logované zprávě neobjeví BĚŽNÝ znak, je hloupost. Nemluvě o tom, že třeba stacktracy \n vždycky obsahují - a nechceš mít jeden stacktrace rozdělený na dvacet samostatných zpráv. Čili minimálně pro jakýkoliv jazyk, který v případě chyby vyhodí stacktrace je to no-go.
Můžeš si to klidně tisknout v jsonu a pak si to někde v log managementu naparsovat. Popravdě syslog zas tak špatný není, máš tam severitu a to je vlastně asi nejdůležitější. Ale ono je typické takové to "jsem na tomhle systému, z nějakého důvodu mi neběží X, co se stalo". A pokud to něco vypsalo, přes journalctl to snadno najdeš.
Však jo, syslog je v pohodě (když máš nad ním nějaký ten strukturovaný formát). Ale opakuju otázku: jaké strukturované formáty podporuje systemd-logger, pokud aplikace loguje na stderr? Pokud chci jeho logy dostat do rsyslogd, jak mi je předá? Rozdělí podle \n? To ale nechci. Mám možnost ho donutit k jinému chování? Kolik hodin/dní/týdnů to budu zjišťovat? Kolik hacků budu muset udělat, abych dosáhl chování, které už jsem měl odladěné? Kolik hodin/dní/týdnů bude nalezené nové řešení fungovat, než se někdo v upstreamu rozhodne to změnit?
Chápej, tohle jsou otázky, které adminy zajímají. Ne nějakej přiblblej rychlejší boot a "čistější" popisy služeb.
Pokud tím myslíš z důvodu věcí, které systemd přináší, tak teda nesouhlasím, pro mě to teda výrazný krok dopředu je.
No ale ještě jsi neuvedl jedinou věc, která by už dávno nebyla vyřešená i bez systemd a která by zároveň výrazně pálila výrazné množství adminů...
-
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" ... ale ten první nechápu. Pořád.
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Tak to zkus otočit. Když admin spustí nějakou službu, a ona se nechová jak potřebuje, tak jak to fixne? Správně je samozřejmě upravit ty deklarativní unit soubory. To je ok. Ale co když, chudák, narazí zrovna na bug v init systému? On to potřebuje vyřešit. Hrábnutí do scriptů je sice prasečina největší, ale je to řešení. Službu nahodí, a pak začne řešit, co s tím. Dělat to naopak je děs.
Ale on ti nikdo nebrání spustit ten servis z ruky, že?
-
Konkrétní příklad: triviální chyba ve startup skriptu služby v Ubuntu. Ticket bez opravy visí v bugzille rok: https://plus.google.com/+MiroslavPrymek/posts/TAYTy8DHMLq Co myslíš, že má admin udělat? Opravit to a mít stabilní server, nebo rok čekat, až se někdo v Canonicallu rozhoupe?
Admin ma mit zaplaceny support, aby to ta firma opravila. Bez supportu se vsak vsechno bastli zleva zprava a jsou to pak mnohdy nedokumentovane zmeny, o kterych nikdo nevi.
A co se tyce rozhodovani o zmenach, IT je tak dynamicky obor, ze pokud je nekdo prilis konzervativni, tak je to mnohdy ke skode - klasikou jsou superstare SW, kvuli kterym se musi drzet stary HW/OS, protoze to na novejsim nebezi. A to jsou mnohdy zvysene naklady. On management taky nebude jezdit autem z roku razdva, ale bude radeji pouzivat novejsi.
-
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" ... ale ten první nechápu. Pořád.
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Tak to zkus otočit. Když admin spustí nějakou službu, a ona se nechová jak potřebuje, tak jak to fixne? Správně je samozřejmě upravit ty deklarativní unit soubory. To je ok. Ale co když, chudák, narazí zrovna na bug v init systému? On to potřebuje vyřešit. Hrábnutí do scriptů je sice prasečina největší, ale je to řešení. Službu nahodí, a pak začne řešit, co s tím. Dělat to naopak je děs.
Ale on ti nikdo nebrání spustit ten servis z ruky, že?
Ještě aby to tak.
To máš těžký, oni jsou admini rozmazlený z toho, že očekávaj, že ten init bude fungovat. A když nefunguje, tak alespoň, že to de nějak poštelovat.
Takže otázka zní, jde systemd poštelovat, když tam autoři nechají nějakou chybu? A je to argumentace na to, proč je to ve scriptech, proč se obecně adminům nezamlouvá binárka.
K tomu si přičti i skutečnost, že v opravdové nouzi ten admin tu zlobící službu prostě vyřadí, a nějak to spáchá sám. Což ale, jak se zdá, taky tak docela nejde. Respektive SystemD tomu klade tuhý odpor.
-
Admin ma mit zaplaceny support, aby to ta firma opravila.
:))) Chtěl bych vidět tu cenu supportu za službu "opravíme vám cokoliv do 24 hodin, abyste do ničeho nemuseli sahat". Jistě by to byla velmi výhodná koupě :)
Bez supportu se vsak vsechno bastli zleva zprava a jsou to pak mnohdy nedokumentovane zmeny, o kterych nikdo nevi.
A proč by o nich nikdo neměl vědět? Admin konfiguruje a konfigurace se řeší konfiguračním managementem, každá změna je zdokumentovaná.
To, že je potřeba něco opravit, přece neznamená, že se sshčknu na server, udělám to ručně a do pěti minut zapomenu.
pokud je nekdo prilis konzervativni
Jistě, "příliš X" je vždycky špatně. Třeba příliš obecná tvrzení jsou úplně k ničemu.
-
Konkrétní příklad: triviální chyba ve startup skriptu služby v Ubuntu. Ticket bez opravy visí v bugzille rok: https://plus.google.com/+MiroslavPrymek/posts/TAYTy8DHMLq Co myslíš, že má admin udělat? Opravit to a mít stabilní server, nebo rok čekat, až se někdo v Canonicallu rozhoupe?
Admin ma mit zaplaceny support, aby to ta firma opravila. Bez supportu se vsak vsechno bastli zleva zprava a jsou to pak mnohdy nedokumentovane zmeny, o kterych nikdo nevi.
Admin je jen Support in House. Co asi myslíš, že ten Support udělá? Je v úplně stejné situaci.
-
Takže otázka zní, jde systemd poštelovat
A taky shellscripty můžeš poštelovat nezávisle na už běžících službách. Ale zkus si opatchovat PID 1 a spustit pomocí něj novou službu...
-
Takže otázka zní, jde systemd poštelovat, když tam autoři nechají nějakou chybu? A je to argumentace na to, proč je to ve scriptech, proč se obecně adminům nezamlouvá binárka.
A co když autoři nechají chybu v libc?
K tomu si přičti i skutečnost, že v opravdové nouzi ten admin tu zlobící službu prostě vyřadí, a nějak to spáchá sám. Což ale, jak se zdá, taky tak docela nejde. Respektive SystemD tomu klade tuhý odpor.
[/quuote]
Opakuji otázku: ten servis snad nejde spustit z ruky?
-
Takže otázka zní, jde systemd poštelovat, když tam autoři nechají nějakou chybu? A je to argumentace na to, proč je to ve scriptech, proč se obecně adminům nezamlouvá binárka.
A co když autoři nechají chybu v libc?
A jaký je to hukot, když se tam najde?
K tomu si přičti i skutečnost, že v opravdové nouzi ten admin tu zlobící službu prostě vyřadí, a nějak to spáchá sám. Což ale, jak se zdá, taky tak docela nejde. Respektive SystemD tomu klade tuhý odpor.
Opakuji otázku: ten servis snad nejde spustit z ruky?
Eh, špatně jsem svou odpověď formuloval.
No, tak ji spustím z ruky (předpokládám, že to znamená se přihlásit na ssh). Což znamená, že si musím nějakým způsobem hlídat, že když se server restartne, tak že se mám opět přihlásit, a opět ji pustit. Teď, ono to také nemusí být nutně jen o spouštění, že jo.
No, a nevím jak vy, ale k čemu je mi takovejhle init systém, který mě nutí udržovat si seznam serverů, které musím hlídat, a pak tam ručně něco řešit, protože zautomatizovat to nejde?
Rozdíl je v tom nejde. S hromadou skriptů to zbastlím, bude to hnusný, bude to křehký, a musím to zdokumentovat, a tak, ale běží to samo.
-
Takže otázka zní, jde systemd poštelovat, když tam autoři nechají nějakou chybu? A je to argumentace na to, proč je to ve scriptech, proč se obecně adminům nezamlouvá binárka.
A co když autoři nechají chybu v libc?
A jaký je to hukot, když se tam najde?
Takže jsme opět u toho, že problém je, že programátoři systemd jsou neschopní, nikoliv u problému se systemd jako takovým? Platily by vaše námitky úplně stejně, pokud by systemd fungovalo bez chyby a autoři by bugy řešili promptně a rychle?
Eh, špatně jsem svou odpověď formuloval.
No, tak ji spustím z ruky (předpokládám, že to znamená se přihlásit na ssh). Což znamená, že si musím nějakým způsobem hlídat, že když se server restartne, tak že se mám opět přihlásit, a opět ji pustit. Teď, ono to také nemusí být nutně jen o spouštění, že jo.
No, a nevím jak vy, ale k čemu je mi takovejhle init systém, který mě nutí udržovat si seznam serverů, které musím hlídat, a pak tam ručně něco řešit, protože zautomatizovat to nejde?
Rozdíl je v tom nejde. S hromadou skriptů to zbastlím, bude to hnusný, bude to křehký, a musím to zdokumentovat, a tak, ale běží to samo.
Tak tohle byla odpověď primárně na to, že si tady někteří stěžovali, že když něco nefunguje, tak se systemd nemůžou nic, zatímco s init skriptem "nějak" spustí tu službu a pak jdou řešit problém. Tak "nějak" spustit službu můžou i z ruky.
Jinak napsat něco do /etc/rc.local jde i v systemd, pokud to nějak funguje. Takže to jde i s restartem - než se podaří problém vyřešit nějakým systémovějším způsobem.
-
Takže jsme opět u toho, že problém je, že programátoři systemd jsou neschopní, nikoliv u problému se systemd jako takovým? Platily by vaše námitky úplně stejně, pokud by systemd fungovalo bez chyby a autoři by bugy řešili promptně a rychle?
Ne, problém je primárně v tom, že u systemd jsi upstreamu víc vydán na milost a nemilost. Což je právě ta nejistota, o které pořád mluvím.
-
A mimochodem, dá se předpokládat, že systemd bude dál Windowsovatět, takže časem bude služba napojená na nějaký kdovíjaký shim (nějaký spešl adhoc dbus socket nebo jánevímco), takže normálně v terminálu už ani spustit nepůjde.
Jasně, je to argumentace šikmou plochou, ale imho je to legitimní obava. A kdyby se to naplnilo, tak je Linux definitivně v zadeki.
-
Takže otázka zní, jde systemd poštelovat, když tam autoři nechají nějakou chybu? A je to argumentace na to, proč je to ve scriptech, proč se obecně adminům nezamlouvá binárka.
A co když autoři nechají chybu v libc?
A jaký je to hukot, když se tam najde?
Takže jsme opět u toho, že problém je, že programátoři systemd jsou neschopní, nikoliv u problému se systemd jako takovým? Platily by vaše námitky úplně stejně, pokud by systemd fungovalo bez chyby a autoři by bugy řešili promptně a rychle?
Obávám se, že by se našli i jiné výtky, ohledně architektury a vynucování SystemD... ale, Ne, neplatili. Když by vývojáři SystemD řešili bugy opravdu promptně, trochu udržovali API tak, aby vydrželo aspoň rok, tak bychom byli v úplně jiné situaci.
Ono po pravdě, když by byli programátoři systemd schopní, tak by i pravděpodobně navrhli i lepší architekturu.
Jenže k čemu je takovéhle "kdyby"?
-
Obávám se, že by se našli i jiné výtky, ohledně architektury a vynucování SystemD... ale, Ne, neplatili. Když by vývojáři SystemD řešili bugy opravdu promptně, trochu udržovali API tak, aby vydrželo aspoň rok, tak bychom byli v úplně jiné situaci.
Ono po pravdě, když by byli programátoři systemd schopní, tak by i pravděpodobně navrhli i lepší architekturu.
Jenže k čemu je takovéhle "kdyby"?
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
V cem se Vas komentar lisi od situace se initem a shell scripty?
-
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
Ne, neplakal. Prymek si to opravil sam.
-
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
V cem se Vas komentar lisi od situace se initem a shell scripty?
Když by ten bug v initu byl v SystemD, jak ho opravím? Šlo by to?
-
Ale on ti nikdo nebrání spustit ten servis z ruky, že?
Ale brani. Systemd zavedl na Linux jednu featuru z windows. Sluzby spoustene z ruky maji jine limity nez sluzby spustene pred systemd. Soubor limits.conf se sice tyka uzivatele, ale pouze pokud se prihlasi. Takze mi vlastne nic nebrani, ale musim myslet na to, ze sluzba spoustena "z ruky" se muze chovat jinak.
-
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
V cem se Vas komentar lisi od situace se initem a shell scripty?
Když by ten bug v initu byl v SystemD, jak ho opravím? Šlo by to?
Kdyz by ten bug byl v /sbin/init (helemese, binarka), jak ho opravite? Slo by to?
-
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
V cem se Vas komentar lisi od situace se initem a shell scripty?
Když by ten bug v initu byl v SystemD, jak ho opravím? Šlo by to?
Kdyz by ten bug byl v /sbin/init (helemese, binarka), jak ho opravite? Slo by to?
[[ Troll detected ]]
-
Kdyz by ten bug byl v /sbin/init (helemese, binarka), jak ho opravite? Slo by to?
Tak každý může riziko posoudit sám, že :)
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=upstart&product=Red%20Hat%20Enterprise%20Linux%206&query_format=advanced
= 28 chyb upstartu v RHEL 6
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=systemd&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced
= 425 chyb systemd v RHEL 7
-
....
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Nikoli, ten script proste dela co ma, a KDOKOLI to umi validovat a pripadne opravit. Systemd dela "vi buh co" a NIKDO ve skutecnosti nevi, co se uvnitr deje. Tudiz to ani neumi opravit (ani sam tvurce, a proto bugy prohlasuje za vlastnost).
A svepravnej admin nikdy nepripusti aby nekde mel blackbox, do kderyho neco hodi a (mozna) mu z nej neco vypadne.
Tak to zkus otočit. Když admin spustí nějakou službu, a ona se nechová jak potřebuje, tak jak to fixne? Správně je samozřejmě upravit ty deklarativní unit soubory. To je ok. Ale co když, chudák, narazí zrovna na bug v init systému? On to potřebuje vyřešit. Hrábnutí do scriptů je sice prasečina největší, ale je to řešení. Službu nahodí, a pak začne řešit, co s tím. Dělat to naopak je děs.
Presne, pokud servis z ruky nastartuje a z init scriptu ne, tak si napisu vlastni script "naprasaka" tak, aby to nastartovalo, a teprve pak se budu zaobirat tim, kde je zakopanej pes. Do normalniho distra pak mozna reportnu bug a zpatky se mi mozna casem vrati odbugovanej script. V pripade systemd se tak mozna dovim, ze sem debil, protoze sem nepochopil ideu "o velkyho poetteringa" ...
Kolik hodin/dní/týdnů bude nalezené nové řešení fungovat, než se někdo v upstreamu rozhodne to změnit?
Tohle je dalsi zcela zasadni aspekt - ten projekt je totalne unstable, a s kazdou dalsi revizi se chova zcela jinak.
Ale on ti nikdo nebrání spustit ten servis z ruky, že?
Jasne a pak u toho budes 10 let sedet 24/7 a cekat az nekdo opravi init, aby to startovalo samo ...
Admin ma mit zaplaceny support, aby to ta firma opravila. Bez supportu se vsak vsechno bastli zleva zprava a jsou to pak mnohdy nedokumentovane zmeny, o kterych nikdo nevi.
Ok, prid, zaplatim si u tebe support, ocekavam odstraneni chyby (nikoli pindy) do maximalne 2 dnu. Garantovane pod penalem. V pripade kritickych sluzeb pak do maximalne 2 hodin.
A taky shellscripty můžeš poštelovat nezávisle na už běžících službách. Ale zkus si opatchovat PID 1 a spustit pomocí něj novou službu...
Tak widle taky treba restartovat aspon kazdej den ... tak budem holt denne restartovat tuxe ...
Takže jsme opět u toho, že problém je, že programátoři systemd jsou neschopní, nikoliv u problému se systemd jako takovým? Platily by vaše námitky úplně stejně, pokud by systemd fungovalo bez chyby a autoři by bugy řešili promptně a rychle?
Platily by uplne stejne protoze integrujou do jednoho binarniho blobu naprosto nesouvisejici veci coz generuje prusery samo o sobe zcela bez ohledu na kvalitu tvurce. Navic binarni blob si admin proste nepoladi, natoz za behu. A kdyz si ho poladi, tak to povede k tomu, ze bude mit distro ktery si bude muset udrzovat sam. Tudiz je pro nej o 10 radu efektivnejsi se systemd vyhnout, a to i za cenu kompletni migrace vseho jinam, protoze to udela jednou, kdezto systemd bude resit denne.
-
Zrovna před chvílí...
Přišly nějaké aktualizace, včetně kernelu (stejná verze, jen nějaké patche)... A co na to systemd?
$ sudo systemctl status mysql
Failed to get D-Bus connection: Neznámá chyba -1
$ sudo systemctl stop mysql
Failed to get D-Bus connection: Neznámá chyba -1
Do té doby funkční. ;-)
A o tom to je, proč systemd nemám(e) rádi.
-
pretoze sa to neda citat.
-
Failed to get D-Bus connection: Neznámá chyba -1
Úplně jak na Windows :))
-
Kdyz by ten bug byl v /sbin/init (helemese, binarka), jak ho opravite? Slo by to?
Tak každý může riziko posoudit sám, že :)
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=upstart&product=Red%20Hat%20Enterprise%20Linux%206&query_format=advanced
= 28 chyb upstartu v RHEL 6
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=systemd&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced
= 425 chyb systemd v RHEL 7
Upstart je 100x horsi ako SystemD. Pouziva ptrace a rozhoduje sa podla PID, takze ak sa zmeni spustana sluzba tak Upstart niekedy nadalej sleduje stare PID, ktore uz neexistuje. A pri troche stastia sa PID zacnu recyklovat pocas updatu systemu a nieco ako "service moj-demon stop" vam killne sshd, lebo ono si dovolilo mat rovnake PID ako mal kedysi davno ten moj-demon. A moj-demon si spokojne bezi dalej.
Dalsi problem je, ak chce program sam byt ptraceovany od niekoho ineho. To nepojde, lebo ptrace je predsa vyhradeny pre Upstart.
Uzivatel musi spravne tipnut, kolko forkov bude od spustenia po beh demona. Ak sa to nepodari, tak by mal pre istotu rebootovat, inak mu hrozi to, co som pisal vyssie.
SystemD ma tiez svoje chyby, ale vacsina je o pristupe spravcov. Napriklad zavislost na DBus a tlacenie nevyhovujuceho KDBusu do kernelu spolu so zavedenim zavislosti na nom. Dalej pohltenie udevd a nedodrzanie slubu o tom, ze bude udevd udrzovane samostatne. Binarne logy su kapitola sama osebe. Divne configy, ktore by sa mali upravovat a potom parsovat urcenymi skriptami tiez nemam rad.
-
Failed to get D-Bus connection: Neznámá chyba -1
Úplně jak na Windows :))
No už jsem to samozřejmě vyřešil, zkušeností jsem už nabral s tímhle kusem softu hromadu, ale to tápání a zkoušení, protože se není čeho chytit (ne v logu fakt nic není)... Prostě na to si fakt zvykat nechci, jak píšu výše...
-
Upstart je 100x horsi ako SystemD.
Ta statistika není o tom, co je horší, ale v čem je hlášeno víc chyb.
-
Kdyz by ten bug byl v /sbin/init (helemese, binarka), jak ho opravite? Slo by to?
Tak každý může riziko posoudit sám, že :)
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=upstart&product=Red%20Hat%20Enterprise%20Linux%206&query_format=advanced
= 28 chyb upstartu v RHEL 6
https://bugzilla.redhat.com//buglist.cgi?classification=Red%20Hat&component=systemd&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced
= 425 chyb systemd v RHEL 7
Upstart je 100x horsi ako SystemD.
Nemám a navíc se netýká tématu. A to že existuje něco horšího neznamená, že mám brát jiné špatné.
Pouziva ptrace a rozhoduje sa podla PID, takze ak sa zmeni spustana sluzba tak Upstart niekedy nadalej sleduje stare PID, ktore uz neexistuje. A pri troche stastia sa PID zacnu recyklovat pocas updatu systemu a nieco ako "service moj-demon stop" vam killne sshd, lebo ono si dovolilo mat rovnake PID ako mal kedysi davno ten moj-demon. A moj-demon si spokojne bezi dalej.
Dalsi problem je, ak chce program sam byt ptraceovany od niekoho ineho. To nepojde, lebo ptrace je predsa vyhradeny pre Upstart.
Uzivatel musi spravne tipnut, kolko forkov bude od spustenia po beh demona. Ak sa to nepodari, tak by mal pre istotu rebootovat, inak mu hrozi to, co som pisal vyssie.
To mají v Ubuntu blbé, já to nemám a nepotřebuji.
SystemD ma tiez svoje chyby, ale vacsina je o pristupe spravcov. Napriklad zavislost na DBus a tlacenie nevyhovujuceho KDBusu do kernelu spolu so zavedenim zavislosti na nom. Dalej pohltenie udevd a nedodrzanie slubu o tom, ze bude udevd udrzovane samostatne. Binarne logy su kapitola sama osebe. Divne configy, ktore by sa mali upravovat a potom parsovat urcenymi skriptami tiez nemam rad.
KDBus nemám.... Co je špatného na mém přístupu, že jsem aktualizoval systém a při příštím startu psal systemd chybu při komunikaci s dbus, když ostatní softy si s dbus vesele komunikovaly?
PS: Už jsem se zmínil, že mi dlouhodobě nefunguje "systemctl disable mysql"? Když odstraním linky v /etc/systemd/system/ ručně, tak pohoda a mysql nestartuje na mé stanici automaticky po bootu. Ale systemctl, které je součástí systemd a má to umět v první řadě, to očividně nezvládá. A o tom je.
-
Okolo systemd myslim celkem plati heslo, ze psi stekaji, ale karavana jede dal :-)
Stary init byl neskutecny bordel (moznost zasahu do nej nejakym kreativnim administratorem beru spise jako minus - po takovych expertech par neco spravovat, resit upgrade - diky nechci), ktery navic nic neumel.
Hezky to vystihnul i Linus:
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.
systemd je rozhodne krok spravnym smerem (nejenom jako init system, protoze to systemd davno neni, ale jako unifikovane zakladni komponenty OS), samozrejme neni bezchybny. Ale treba ten bugreport z RH je dost mimo, pokud si prectete ty jednotlive bugreporty, tak se jen mala cast tyka opravdu systemd a ne RH samotneho :)
Osobni zkusenost ? Nekolik set nodu RHEL/Centos s systemd, nekolik desktopu, a zadny zasadni problem :) A rozhodne nevidim problem v logovani - logujeme vse centralne na logstash bezproblemu (ktery ma uz btw primou popdporu pro journal).
Za me osobne ma systemd velke plus, je to krok spravnym smerem, z Linuxovych systemu rozhodne nechci skanzen :)
-
Zrovna před chvílí...
Přišly nějaké aktualizace, včetně kernelu (stejná verze, jen nějaké patche)... A co na to systemd?
$ sudo systemctl status mysql
Failed to get D-Bus connection: Neznámá chyba -1
$ sudo systemctl stop mysql
Failed to get D-Bus connection: Neznámá chyba -1
Do té doby funkční. ;-)
A o tom to je, proč systemd nemám(e) rádi.
Presne, dbus nema na serveru vubec do pohledavat ...
Failed to get D-Bus connection: Neznámá chyba -1
Úplně jak na Windows :))
Tak widle to dotahly uz tak daleko, ze se nenechaj ani vypnout, kdyz se nejakej servis rozhodne, ze komunikovat nebude. Takze si musis dojit sahnout na power fyzicky.
Upstart je 100x horsi ako SystemD. Pouziva ptrace a rozhoduje sa podla PID, takze ak sa zmeni spustana sluzba tak Upstart niekedy nadalej sleduje stare PID, ktore uz neexistuje. A pri troche stastia sa PID zacnu recyklovat pocas updatu systemu a nieco ako "service moj-demon stop" vam killne sshd, lebo ono si dovolilo mat rovnake PID ako mal kedysi davno ten moj-demon. A moj-demon si spokojne bezi dalej.
Aha, ty vubec netusis ze? Kupodivu zadnej demon nenastartuje, pokud si sam nevytvori vlastni pid. Pokud nejaky existuje, tak to v ramci startu smazne, a pokud to nejde, tak proste uz pri startu vyhodi bug.
-
systemd je rozhodne krok spravnym smerem (nejenom jako init system, protoze to systemd davno neni, ale jako unifikovane zakladni komponenty OS), samozrejme neni bezchybny.
Napsani noveho initu mozna je spravnym krokem, ale kdyz ten krok byl nasmerovan smerem k systemd, tak se ukazalo, ze tam lezi obrovske hovno, co se sklebi ja Poettering.
-
Presne, dbus nema na serveru vubec do pohledavat ...
Včera jsem si s velkým zájmem pročítal dlouhou diskusi o pull requestu na kdbus: http://thread.gmane.org/gmane.linux.kernel/1930358
Kromě toho, že si i někteří vývojáři jádra museli ujasňovat, co vlastně znamená big-O notace a jak ji používat :) (ať mi ještě někdo chvilku tvrdí, jak je teorie důležítá a jak ji potřebuje znát každý absolvent...), tak velmi výživné bylo číst o tom, jaká nedůvěra k lidem kolem systemd mezi některými kerneláři panuje:
> You don't have to enable the metadata if you don't want to use
> it,
> it's
> an option :)
OK, _that_ argument needs to be stomped out. It had been used before,
and it was a deliberate scam. There is no such thing as optional
kernel interface, especially when udev/dbus/systemd crowd is
nearby. [...]
This is a huge red flag. On the level of "I need your account
information to transfer $200M you might have inherited from my
deceased client".
Just to recap how it went the last time around: Kay kept pushing his piece of
code into the tree, claiming that it was optional, that nobody who doesn't
like it has to enable it, so what's the problem? OK, in it went. And pretty
soon udev (maintained by the same... meticulously honorable person) had
stopped working on the kernels that didn't have that enabled.
We had been there before. To paraphrase another... meticulously honorable
person, "if you didn't want something relied upon, why have you put it into the
kernel?" Said person is on the record as having no problem whatsoever with
adding dependencies to the bottom of userland stack.
Dobrý žrádlo. Ani se nendivím Alanovi Coxovi, že:
https://plus.google.com/u/0/+AlanCoxLinux/posts/a2jAP7Pz1gj
-
Zjevne se snazej kernel zaintegrovat do systemd ... a pak uz snadno dosahnou toho, ze bez systemd nebude fungovat nic. A voiala, mame tu dalsi widle.
-
Nesmysl. Kernel bude z linuxovych dister vypusten, protoze by zbytecne duplikoval funkcionalitu systemd.
-
Ale on ti nikdo nebrání spustit ten servis z ruky, že?
Ale brani. Systemd zavedl na Linux jednu featuru z windows. Sluzby spoustene z ruky maji jine limity nez sluzby spustene pred systemd. Soubor limits.conf se sice tyka uzivatele, ale pouze pokud se prihlasi. Takze mi vlastne nic nebrani, ale musim myslet na to, ze sluzba spoustena "z ruky" se muze chovat jinak.
V tomhle je ovšem systemd nevinně. To samé totiž platí pro SELinux pravidla a nastacení cgroup omezení. A tyhle dvě věci byly jeden z důvodů, proč systemd vzniklo. Uživatel má jiný výchozí kontext (i root) než init systém.
-
V tomhle je ovšem systemd nevinně. To samé totiž platí pro SELinux pravidla a nastacení cgroup omezení. A tyhle dvě věci byly jeden z důvodů, proč systemd vzniklo. Uživatel má jiný výchozí kontext (i root) než init systém.
Tyhle linuxové novoty už moc nesleduju, takže možná teď plácnu blbost, ale nesrovnáváš trošku hrušky s jabkama? SELinux se dá vypnout, pravidla se dají dočasně nastavit jinak. Pokud ale systemd funguje tak, že službu umístí do nějaké "karantény" (na detailech nezáleží), v ní ti služba nebude fungovat a spuštěna z terminálu bude, tak seš v pytli a babo raď. Jak uděláš bisect? SELinux můžeš vypnout, můžeš ho přepnout do permissive, můžeš postupně ubírat pravidla. Co uděláš s pevně nastavenou "karanténou" pod systemd? Budeš ho postupně patchovat, překládat, restartovat?!
-
Jako ve widlich, poridis si vetsiho roota nez roota ... alias widle a jejich system account. Neni admin jako admin ... takze v tomhle pripade budes misto widliho ac system, hackovat systemd ... coz vlastne i odpovida nazvem. Abys ziskal jeho kontext a moh zacit resit, proc to kua nefunguje.
-
Napsani noveho initu mozna je spravnym krokem, ale kdyz ten krok byl nasmerovan smerem k systemd, tak se ukazalo, ze tam lezi obrovske hovno, co se sklebi ja Poettering.
Ten Potěr-ing mi připadá jako mamánek, či spíše mamrd (motherfucker)? Ten druhý Kay-Si-nevrz, o tom by jeden můj kolega řekl, že je to typický OVÁD.
-
Napsani noveho initu mozna je spravnym krokem, ale kdyz ten krok byl nasmerovan smerem k systemd, tak se ukazalo, ze tam lezi obrovske hovno, co se sklebi ja Poettering.
Ten Potěr-ing mi připadá jako mamánek, či spíše mamrd (motherfucker)? Ten druhý Kay-Si-nevrz, o tom by jeden můj kolega řekl, že je to typický OVÁD.
Tím, že je takto urážíte děláte kritikům SystemD medvědí službu.
-
Kromě toho, že si i někteří vývojáři jádra museli ujasňovat, co vlastně znamená big-O notace a jak ji používat :) (ať mi ještě někdo chvilku tvrdí, jak je teorie důležítá a jak ji potřebuje znát každý absolvent...)
Samozřejmě, že je. A tohle to jen dokazuje. Že se na vývoji jádra dnes podílejí fachidioti přece není důkaz, že vývoj jádra mohou dělat i fachidioti. Tohle rozhodně není ideální stav. A je to i důvod, proč například velké průmyslové firmy do svých zařízení dodávají raději své proprietární embedded OS, než riskovat Linux. To se týká i naší vcelku malé firmy, kdy po poměrně dlouhé a zralé úvaze bylo nakonec rozhodnuto vyvinout vlastní OS, který, přestože bude nepoměrně štíhlejší než Linux, dohromady bude představovat více práce, než nějak přiohnout Linux. Jenže opravdu nechceme trnout hrůzou, že výpadek nějaké linky, který by nás jakožto dodavatele stál statisíce, vlastně způsobil kus kódu nějakého bezejmenného idiota, co ani nevěděl, co je O-notace. A co všechno ještě nevěděl a nebral v úvahu při programování, hm?
-
...
A proto budete riskovat ze vypadek linky zpusobi kod idiota, co sice teorii zvlada, ale netusi, jak vypada zelezo na kterym to bezi a o tom, co ten kod vlastne dela, nema ani paru.
-
...
A proto budete riskovat ze vypadek linky zpusobi kod idiota, co sice teorii zvlada, ale netusi, jak vypada zelezo na kterym to bezi a o tom, co ten kod vlastne dela, nema ani paru.
To byl určitě vtip, co tam Viky psal...
-
Kromě toho, že si i někteří vývojáři jádra museli ujasňovat, co vlastně znamená big-O notace a jak ji používat :) (ať mi ještě někdo chvilku tvrdí, jak je teorie důležítá a jak ji potřebuje znát každý absolvent...)
Samozřejmě, že je. A tohle to jen dokazuje. Že se na vývoji jádra dnes podílejí fachidioti přece není důkaz, že vývoj jádra mohou dělat i fachidioti. Tohle rozhodně není ideální stav. A je to i důvod, proč například velké průmyslové firmy do svých zařízení dodávají raději své proprietární embedded OS, než riskovat Linux. To se týká i naší vcelku malé firmy, kdy po poměrně dlouhé a zralé úvaze bylo nakonec rozhodnuto vyvinout vlastní OS, který, přestože bude nepoměrně štíhlejší než Linux, dohromady bude představovat více práce, než nějak přiohnout Linux. Jenže opravdu nechceme trnout hrůzou, že výpadek nějaké linky, který by nás jakožto dodavatele stál statisíce, vlastně způsobil kus kódu nějakého bezejmenného idiota, co ani nevěděl, co je O-notace. A co všechno ještě nevěděl a nebral v úvahu při programování, hm?
Tyjo nevím nevím, ale podobné projekty končí taky dost špatně. Ono se začne na zelené louce, vyvíjí se vyvíjí a nic není vidět (resp. peníze se do toho lejou a zákazníci platí za něco úplně jinýho, co se jim paralelně dodává). Potom postupně odejdou původní vývojáři (nebo i zůstanou) a začíná se záplatovat, protože:
1) však to voe vopravím teď jako narychlo, bo šéf mi stojí za zády. _potom_ to uděláme pořádně
2) já teď jako vůbec nevím, jak to funguje, ale tady si to pěkně přiohnu, _potom_ to uděláme pořádně
3) ajo naši guru odešli jinam, ale to neva, ten OS už vlastně _skoro_ je hotový a tadyhle Pepa, co dokončil VŠ, to už spíchne
-
Tyjo nevím nevím, ale podobné projekty končí taky dost špatně.
Tak nevíme, o jakém zařízení Viki mluví, třeba to je "OS" pro tři tranzistory, který jsou schopní inhouse i formálně verifikovat, co ty víš :) Ale jinak to samozřejmě vypadá jako klasický NIH syndrom. Různých RTOSů jsou na světě mraky, moc si nedovedu představit, že by "vcelku malá" firma nutně potřebovala vlastní a napsala by ho kvalitněji než ty existující, industriálně prověřené :)
-
...
A proto budete riskovat ze vypadek linky zpusobi kod idiota, co sice teorii zvlada, ale netusi, jak vypada zelezo na kterym to bezi a o tom, co ten kod vlastne dela, nema ani paru.
Někteří zdejší idioti si zřejmě vůbec nedokáží představit, že existují lidé, co znají teorii a zároveň železo, protože ho sami navrhují. Bohužel jsi intelektuálně méněcenný a domníváš se, že všichni ostatní jsou jako ty. Ale my se ti nesmějeme, my tě jen litujeme. Nechtěli bychom dopadnout jako ty.
-
Koukám, že se to tady docela zvrhlo :(
Lidi, kteří si sami navrhují železo asi nemají potřebu ptát se na rootu, co je pro ně nejlepší, nemáte ten pocit?
-
Diskuse dospela do stadia, kdy by si nekteri zucastneni meli jit premerit pindoura, aby se vedelo, kdo ma pravdu.
-
Diskuse dospela do stadia, kdy by si nekteri zucastneni meli jit premerit pindoura, aby se vedelo, kdo ma pravdu.
To je dětinské! Navrhuju porovnávat benchmarky. Vyzvaný může vybírat mezi unixbenchem a sysbenchem.
-
Diskuse dospela do stadia, kdy by si nekteri zucastneni meli jit premerit pindoura, aby se vedelo, kdo ma pravdu.
To je dětinské! Navrhuju porovnávat benchmarky. Vyzvaný může vybírat mezi unixbenchem a sysbenchem.
Jak detinske? V Knoflikove valce to fungovalo spolehlive a urcite ne jen v te.
-
...
A proto budete riskovat ze vypadek linky zpusobi kod idiota, co sice teorii zvlada, ale netusi, jak vypada zelezo na kterym to bezi a o tom, co ten kod vlastne dela, nema ani paru.
Někteří zdejší idioti si zřejmě vůbec nedokáží představit, že existují lidé, co znají teorii a zároveň železo, protože ho sami navrhují. Bohužel jsi intelektuálně méněcenný a domníváš se, že všichni ostatní jsou jako ty. Ale my se ti nesmějeme, my tě jen litujeme. Nechtěli bychom dopadnout jako ty.
Vysosti, az si vsimnou kde tu zadek maji, tak do ni strcej hlavu az po kotniky!...
-
Vysosti, az si vsimnou kde tu zadek maji, tak do ni strcej hlavu az po kotniky!...
Jo pane, *prdel* se pise takle.
-
Akurat vcera som skusal kubuntu 16.04 a potom debian testing s KDE5. Skusenosti hrozne, zbytocne zabity skoro cely den :-\ Problemy boli s ovladacmi (spociatku mrzli X na obidvoch systemoch kym som nenahodil nvidia ovladace, nemohol som prejst do konzoly s ctrl+alt+f1), na kubuntu sa mi rozsypal dizajn (widgety a pod.) , resp. odzaciatku nefungoval dobre. Pod debianom mi neslo prihlasovanie, tak som nahodil gnome3, ale pod gdm3 zavadzacom mi X-ka do 2-3 minut po spusteni padli a o chvilu sa restartovali. Funkcne bolo az gnome pod lightdm (tusim). Gnome ale moc nemusim, tak som skusil spustit kde pod sddm, potom uz prihlasovanie nejakym zazrakom slo. Potom som instaloval + config lm-sensors, gkrellm a dalsie veci. Po restarte, co nevidim, emergency mode kde system 1,5 minuty akoze nieco robi a z vypisu systemctl som prd zistil. Graficky system samozrejme nesiel. Na KDE5 som tiez pobadal posahany taskbar - niekedy hodi bug report. Tak som hladal distro bez systemd a nainstalil PClinuxOS (KDE4). Az na nejake detaily to slape, len mi tu chyba lepsia podpora 2 monitorov, nepamata si nastavenie >:( Davnejsie som mohol kludne pouzivat testing distra s novym jadrom / balickami, ale asi systemd to cele kazi.
-
Akurat vcera som skusal kubuntu 16.04 a potom debian testing s KDE5. Skusenosti hrozne, zbytocne zabity skoro cely den :-\ Problemy boli s ovladacmi (spociatku mrzli X na obidvoch systemoch kym som nenahodil nvidia ovladace, nemohol som prejst do konzoly s ctrl+alt+f1), na kubuntu sa mi rozsypal dizajn (widgety a pod.) , resp. odzaciatku nefungoval dobre. Pod debianom mi neslo prihlasovanie, tak som nahodil gnome3, ale pod gdm3 zavadzacom mi X-ka do 2-3 minut po spusteni padli a o chvilu sa restartovali. Funkcne bolo az gnome pod lightdm (tusim). Gnome ale moc nemusim, tak som skusil spustit kde pod sddm, potom uz prihlasovanie nejakym zazrakom slo. Potom som instaloval + config lm-sensors, gkrellm a dalsie veci. Po restarte, co nevidim, emergency mode kde system 1,5 minuty akoze nieco robi a z vypisu systemctl som prd zistil. Graficky system samozrejme nesiel. Na KDE5 som tiez pobadal posahany taskbar - niekedy hodi bug report. Tak som hladal distro bez systemd a nainstalil PClinuxOS (KDE4). Az na nejake detaily to slape, len mi tu chyba lepsia podpora 2 monitorov, nepamata si nastavenie >:( Davnejsie som mohol kludne pouzivat testing distra s novym jadrom / balickami, ale asi systemd to cele kazi.
Vítej v opensource komunitě, kde nic není udělané pořádně, protože jde o *, až teda na těch pár věcí co mají komerční základ.
Víte co je zajímavé? Nějak v posledních letech přestávám tolik vídat linuxové fanatiky. Kam se všichni poděli?
-
Koukám, že se to tady docela zvrhlo :(
Lidi, kteří si sami navrhují železo asi nemají potřebu ptát se na rootu, co je pro ně nejlepší, nemáte ten pocit?
Tak niektori nemaju potrebu ale zase niektori tu potrebu spytat sa maju
-
Tak som hladal distro bez systemd
V Ubuntu se ZATÍM lze vrátit k upstartu, a to snadným
sudo apt-get install upstart-sysv
Po rebootu jste zpátky v systému s původním initem.
Silně to doporučuji udělat. Systém pak nabíhá a reaguje daleko rychleji a hlavně víte, co od něj máte čekat.
Otázkou je, zda to tak půjde i nadále, nebo je to možné naposledy v 16.04.
Já pevně doufám, že lidi kolem Debianu dostanou rozum a po pár rozdrbaných serverech a diskových polích sklapnou uši a na celý slavný systemd se vybodnou.
-
typický spokojenec uživatel desktopu (typicky jenom proto, že mu to božsky rychle bootuje ;) )
na to mam SSD a ne nejaky programy...
SSD je jedna cast reseni. Init musi byt druha - predstav si, ze mas init, ktery spousti veci jednu za druhou a jedna z tech veci trrrrrvaaaaa (trebas protoze se pokousi o neco na siti...)
Aha... tak to doporučuji zkusit nabootovat pomocí systemd s adresářem mountnutým přes NFS. Taková sranda pak může trvat klidně i minutu, protože se tam donekonečna checkují (neexistující) startup tasky. Zatímco klasický init na tohle (dle mne zcela správně) při bootu nečeká.
-
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
-
Tyjo nevím nevím, ale podobné projekty končí taky dost špatně.
Tak nevíme, o jakém zařízení Viki mluví, třeba to je "OS" pro tři tranzistory, který jsou schopní inhouse i formálně verifikovat, co ty víš :) Ale jinak to samozřejmě vypadá jako klasický NIH syndrom. Různých RTOSů jsou na světě mraky, moc si nedovedu představit, že by "vcelku malá" firma nutně potřebovala vlastní a napsala by ho kvalitněji než ty existující, industriálně prověřené :)
Tak tak. Navic statisice nejsou zadne penize. To je plat par dvou/tri vyvojaru v CR na mesic. Na to si i firma muze vzit i pojistku. Horsi jsou ztraty zacinajici na milionech denne(uvazuji stale malou ci stredni firmu). V prumyslu overene OS jsou certifikovane, formalne verifikovane, s dobrou podporou (kdekoliv clovek zavola a muze mit x hodin na telefonu developera a poslou mu do hodiny patch). Hlavne je to verifikovane i s existujicim hardwarem ktery nemusi byt masove dostupny. Dalsi vec je "knowledge base". Kolik zkusenoych developeru sezenu na PepaZdepaOS a kolik na VxWorks? Kdo poskytne podporu v pripade pruseru?
OS pro tri tranzistory nenazyvam OS, ale primo bezici program bez OS:) Psat OS kvuli mikrovlnce muze jen podceneny hipik z cvut.
-
Čistě moje subjektivní zkušenost:
Nemám nic proti systemd jako initu. Je mi docela ukradené, jestli se píše script, nebo nějaký konfigurák. Zrychlení bootování? Fajn.
Problém je, že systemd není jen init. Ta sračka snědla půlku linuxu a pořád se rozpíná dál. Myslel jsem, že se asi poseru, když jsem před půl rokem dostal v práci pár serverů ať na nich něco udělám a nebyl jsem schopný ani spustit síť, protože půl linuxu bylo nahrazeno systemd blbostma a já se můžu po 10 letech spokojeného adminování v malém všechno přeučit.
Někdo to dobře vyjádřil tímhle gifem:
(https://media.giphy.com/media/5xtDarAgrjoOrBxSVYk/giphy.gif)
Poslední kapka pro mě byly ty jejich plány na nahrazení cronu a teď jak si vymysleli, že budou killovat běžící procesy po odhlášení uživatele, takže tmux, screen a byobu musí dělat úpravy. To ani nepočítám notoricky špatnou podporu a neochotu opravovat bugy celé roky. Celý ten jejich přístup je jedna gigantická arogance ke zbytku komunity.
Myslím, že to je ten důvod, proč jsou „všichni“ proti systemd.
-
Problém je, že systemd není jen init. Ta sračka snědla půlku linuxu a pořád se rozpíná dál.
http://natura.baf.cz/natura/1994/10/9410-10.html
-
Tyjo nevím nevím, ale podobné projekty končí taky dost špatně.
Tak nevíme, o jakém zařízení Viki mluví, třeba to je "OS" pro tři tranzistory, který jsou schopní inhouse i formálně verifikovat, co ty víš :) Ale jinak to samozřejmě vypadá jako klasický NIH syndrom. Různých RTOSů jsou na světě mraky, moc si nedovedu představit, že by "vcelku malá" firma nutně potřebovala vlastní a napsala by ho kvalitněji než ty existující, industriálně prověřené :)
Embedded OS může být velmi minimalistický, problém v tom nevidím. Pracoval jsem ve dvou firmách zabývajících se embedded řešeními a každá měla své proprietární OS. Taktéž nevidím problém v tom, že by se nedal napsat kvalitněji než komerčně dostupné. Komerční OS obsahují spoustu balastu kvůli univerzalitě a rozhodně bych neřekl, že to píšou nějací géniové z jiné planety. Že je něčeho mraky ještě neznamená, že to splňuje specifické požadavky a že je to kvalitní. Pokud jde o různé certifikace, tak se stejně pak certifikuje celé řešení a zde může být v případě externě dodaného OS dokonce problém, protože budete muset dokládat např. neregresní testy - a ty seženete kde?
Váš údiv je způsoben tím, že se v industry automation a embedded evidentně nepohybujete, takže "neznáte mapu". :) Ale toto opravdu není nic výjimečného, spíš naopak.
-
Váš údiv je způsoben tím, že se v industry automation a embedded evidentně nepohybujete, takže "neznáte mapu". :)
Jasně, však jsem nic takovýho ani netvrdil :)
-
Ta sračka snědla půlku linuxu a pořád se rozpíná dál.
Mne to zas pripomenulo scenu z filmu Gridhouse planeta teror :)
https://youtu.be/-2vHpyi1dhU?t=14m50s
"Where is that shit ? Everywhere"
-
Tak widle to dotahly uz tak daleko, ze se nenechaj ani vypnout, kdyz se nejakej servis rozhodne, ze komunikovat nebude. Takze si musis dojit sahnout na power fyzicky.
Stale sa to da fyzicky riesit na dialku. Das dva stroje oproti sebe a pomocou ejectu CD/DVD mechaniky na jednom stroji tuknes do resetu toho druheho.
Horsie by bolo keby obidva stroje zatuhli alebo vypadlo spojenie ;D
-
ted jsem potreboval na debian 8 zmenit dns
tak jsem zapsal konfiguraci do /etc/resolv.conf jako jsem to delal 10 let a vzdycky to bez problemu slo.
ted to zmrdany systemd vsechno prepisuje
debian sel totalne do sracek s prichodem systemd
se nedivim ze jeho zakladatel spachal nedavno sebevrazdu
-
se nedivim ze jeho zakladatel spachal nedavno sebevrazdu
Ale to bolo kvoli niecomu celkom inemu. Pachat samovrazdu kvoli praci, ktoru mozes hocikedy zmenit, je cista blbost.
-
Ale to bolo kvoli niecomu celkom inemu. Pachat samovrazdu kvoli praci, ktoru mozes hocikedy zmenit, je cista blbost.
byla zřejmá nadsázka...
-
Ale to bolo kvoli niecomu celkom inemu. Pachat samovrazdu kvoli praci, ktoru mozes hocikedy zmenit, je cista blbost.
byla zřejmá nadsázka...
A to se pozná jak? Já bych se nedivil, v kombinaci s duševní poruchou která mu znemožnila se účinně bránit proti pronikání systemd...
-
ted jsem potreboval na debian 8 zmenit dns
tak jsem zapsal konfiguraci do /etc/resolv.conf jako jsem to delal 10 let a vzdycky to bez problemu slo.
ted to zmrdany systemd vsechno prepisuje
debian sel totalne do sracek s prichodem systemd
se nedivim ze jeho zakladatel spachal nedavno sebevrazdu
Chyba mezi zidli a klavesnici. Co kdyby jste si zkontroloval konfiguraci site?
-
Proc by mel neco kontrolovat? Tenhle soubor ke konfiguraci DNS slouzi odjakziva. Proto se to taky menuje konfiguracni soubor, zejo ...
-
Dneska se ale na tom musi nastavit immutable atribut.
-
Proc by mel neco kontrolovat? Tenhle soubor ke konfiguraci DNS slouzi odjakziva. Proto se to taky menuje konfiguracni soubor, zejo ...
Protože tenhle soubor stejně tak odjakživa přepisuje třeba DHCP klient.
-
Proc by mel neco kontrolovat? Tenhle soubor ke konfiguraci DNS slouzi odjakziva. Proto se to taky menuje konfiguracni soubor, zejo ...
Protože tenhle soubor stejně tak odjakživa přepisuje třeba DHCP klient.
To neni pravda. Co ja vim, tak DHCP klient prepisuje /run/resolvconf/resolv.conf. /etc/resolv.conf pak byva symlink na nej. Pokud symlink nahradim souborem, DHCP klient se mi do niceho nesere, prepisuje si svuj /run/resolvconf/resolv.conf, coz mi je putna. Pokud tedy systemd opavdu zacal prepisovat /etc/resolv.conf, tak je Poettering jeste vetsi debil, nez jsem se puvodne domnival.
-
Proc by mel neco kontrolovat? Tenhle soubor ke konfiguraci DNS slouzi odjakziva. Proto se to taky menuje konfiguracni soubor, zejo ...
Protože tenhle soubor stejně tak odjakživa přepisuje třeba DHCP klient.
To neni pravda. Co ja vim, tak DHCP klient prepisuje /run/resolvconf/resolv.conf. /etc/resolv.conf pak byva symlink na nej. Pokud symlink nahradim souborem, DHCP klient se mi do niceho nesere, prepisuje si svuj /run/resolvconf/resolv.conf, coz mi je putna. Pokud tedy systemd opavdu zacal prepisovat /etc/resolv.conf, tak je Poettering jeste vetsi debil, nez jsem se puvodne domnival.
V Debianu při vyhledávání DHCP to vyhodí ohledně klientů min toto:
dibbler-client - Přenosný klient DHCPv6
pump - BOOTP a klient DHCP pro automatickou konfiguraci IP
autodns-dhcp - Automatic DNS updates for DHCP
bootp - server for the bootp protocol with DHCP support
udhcpc - Provides the busybox DHCP client implementation
dhcpcd5 - DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
guessnet - Guess which LAN a network device is connected to
isc-dhcp-client - DHCP client for automatically obtaining an IP address
whereami - Automatically reconfigure your (laptop) system for a new location
wide-dhcpv6-client - DHCPv6 client for automatic IPv6 hosts configuration
kterého DHCP klienta myslíte? ;) Dáte ruku do ohně za to, že to všechny dělají stejně jak popisujete? Každopádně DHCP klient obsah /etc/resolv.conf mění, a je celkem jedno, jestli to je soubor nebo symlink. Další běžný program co to mění je resolvconf ap.:
openresolv - management framework for resolv.conf
resolvconf - Obsluha informací o jmenných serverech
avahi-dnsconfd - Avahi DNS configuration tool
myslím, že zkontrolovat konfiguraci sítě byla proto opravdu dobrá rada. Kdo ví co mu tam co přepisuje, třeba v tom je systemd výjimečně nevinně :D
-
Symlink to je, to je pravda, ale kam vede záleží na tom, jakej používáte network manager. Já ho mám třeba směrovanej do /var/run/NetworkManager/resolv.conf. A na debianu oldstable, to mám jako file a nic mi to nepřepisuje :)
-
To neni pravda. Co ja vim, tak DHCP klient prepisuje /run/resolvconf/resolv.conf. /etc/resolv.conf pak byva symlink na nej. Pokud symlink nahradim souborem, DHCP klient se mi do niceho nesere, prepisuje si svuj /run/resolvconf/resolv.conf, coz mi je putna. Pokud tedy systemd opavdu zacal prepisovat /etc/resolv.conf, tak je Poettering jeste vetsi debil, nez jsem se puvodne domnival.
Pokud máš resolvconf, tak DHCP klient většinou zapisuje do něj (ne do resolv.conf v něm, ale do souboru pro příslušné rozhraní). resolvconf pak přepisuje /etc/resolv.conf. Ten symlink se používá, aby to nedělal v /etc, které může být read-only (nebo verzované), ale pokud tam není symlink, tak to přepisuje v /etc. Mimochodem resolvconf je dost nový program, ještě před 10 lety se nepoužíval, takový novoty bys ani neměl ani znát ;) Pokud nemáš resolvconf nainstalovaný, DHCP klient zapisuje přímo do /etc/resolv.conf.
-
@Wily: Dobre, upresneme to: /etc/resolv.conf je typicky symlink, ktery odkazuje na jakysi soubor, mozna podle toho, co se stara o obdrzeni udaju z DHCP serveru, ale za normalnich okolnosti to ma byt do /run/resolvconf/resolv.conf (dle manualu) a /etc/resolv.conf je na to symlink.
Update /run/resolvconf/resolv.conf se normalne dela pomoci resolvconf, nic by nemelo zasahovat do souboru primo. Tedy DHCP klient a dalsi kvuli zmene zavolaji resolvconf. Network Manager si zrejme nastavuje symlink podle sebe sama. Mozna to dela na systemech, kde neni nainstalovan resolvconf. Mate ho nainstalovany?
V kazdem pripade by ale melo platit. ze nic nemeni primo /etc/resolv.conf, protoze je to symlink. Pokud misto nej dam soubor, nic by do toho nemelo zasahovat - alespon to je chovani, ktere jsem videl na svych strojich. Znate pripad, kdy tomu tak neni, ponechame-li stranou systemd, kde si uz clovek nemuze byt nicim jisty?
@Sten: mam nainstalovany resolvconf. V /etc/resolvconf mam natvrdo nameserver 127.0.0.1, v /run/resolvconf/resolv.conf mam z DHCP narvane nameservery od ISP, ktere se timto ignoruji, protoze /etc/resolv.conf je soubor. Do /etc/resolv.conf mi nic nezasahuje, takze to budto funguje jinak, nez si myslis nebo mas novejsi verzi, kde to nejak po Poetteringovsku dokurvili.
-
Ahoj, zkoumal jsem rozdíly mezi systemd a initem a zdá se mi že systemd je postatně lepší, modernější a bezpečnější řešení. Proč jsou všichni správci proti systemd? Většinou totiž řeší všechno, na co si kdy stěžují. Podle mně jsou prostě líní učit se něco nového. Co vy na to?
Ja by som hladl odpoved v clanku
Úvaha: Proč jsou vlastně staří ajťáci konzervativní
autor: Michal Rybka , publikováno 11.1.2013
http://pctuning.tyden.cz/hardware/multimedia-zvuk-tv/26036-uvaha-proc-jsou-vlastne-stari-ajtaci-konzervativni
Zjavne je tu malo mladych
-
Ahoj, zkoumal jsem rozdíly mezi systemd a initem a zdá se mi že systemd je postatně lepší, modernější a bezpečnější řešení. Proč jsou všichni správci proti systemd? Většinou totiž řeší všechno, na co si kdy stěžují. Podle mně jsou prostě líní učit se něco nového. Co vy na to?
Ja by som hladl odpoved v clanku
Úvaha: Proč jsou vlastně staří ajťáci konzervativní
autor: Michal Rybka , publikováno 11.1.2013
http://pctuning.tyden.cz/hardware/multimedia-zvuk-tv/26036-uvaha-proc-jsou-vlastne-stari-ajtaci-konzervativni
Zjavne je tu malo mladych
Jsem spolupracoval na jednom projektu s kamošem, kterej tu svou část práce použil jako bakalářku (takže snad dost mladej). A sice mlčky trpěl, ale dost mu vadilo, že jsem mu každým commitem změnil rozhraní, a on tu svou práci musel furt dokola předělávat.
Tak asi tolik k té konzervativnosti.
-
systemd mam zatial iba na pracovnom laptope. funguje to fajn len si neviem vybavit commandy na ovladanie pretoze som pouzival doterajsie systemy. cital som clanky o tom ako to nefunguje buggy a tak ale osobnu skusenost s tym nemam. jediny padny argument co poznam je ze systemd scripty su necitatelne.
-
Dej si do fstab flešku nebo externí disk nebo samba share, flešku nebo disk nebo samba share odpoj a proveď restart.
Nebo uprav v fstab swap, aby nešel připojit.
Po restartu sem zkus napsat výsledek. :-)
-
Systemd jsem videl poprve v nasem testovacim stroji. Pridal jsem disk, partisna mountovana ve fstabu. Jelo to do te doby nez tam byl ten disk, pri bootu bez disku to ceka 90 vterin zda se neobjevi a pak to selze v startu systemu - v podstate se to blokne v nejakem bode a uz dal nic nefunguje - se neslo ani prihlasit. S klasickym systemem to jenom failnulo a jelo se dal.. a clovek mel moznost pripadny zavadny radek odstranit.