Popravde za celou dobu co distribuce pouzivaji systemd jsem s tim nemel zadny problem (s vyjimkou nutnosti nastudovat si, jak se to konfiguruje).
"systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak. zatim co klasicky init moc nefunguje, ale aspon se verejne vi proc a jak. nahradit takovym ne-uplne-funkcnim init systemem funkcni systemd je pak nemozny, pokud clovek nenapise vlastni init, kterej bude komplexni jako systemd.
To ze systemd integruje spoustu veci je trochu blby z hlediska politiky, protoze hromadi zodpovednost. Nicmene mi to vyresilo spoustu problemu s kompatibilitou a podporou. napriklad demon na ntp synchronizaci funguje v systemd lip nez jakykoliv standalone, ktery jsem pouzival predtim.
Je skupina lidí, kteří si pořád stěžují na problémy se systemd, a pak je skupina těch, kteří na žádný takový problém nenarazili. Nemám na to žádná data ale připadá mi dost možné, že k těm problémům dochází, když se člověk snaží i po zavedení systemd dál používat systém v unixovém stylu, tj. spravovat služby pomocí skriptů, nastavovat síť pomocí ifconfig nebo ip atd. To celkem pochopitelně koliduje s tím, co "pod povrchem" dělá systemd. Jako takový mi systemd připadá dobrý, ale je jisté, že predstavuje skutečně určitý zlom a přerod od Unixu k něčemu jinému. Osobně mi tento zlom připadá velmi žádoucí.
Narazil jsem na několik výhradně systemd bugů, on žádný systém není bez chyb. Pokud ty věci používáte ne jen na uživatelské úrovni, ale chcete po tom něco víc, tak je to hned.
tj. spravovat služby pomocí skriptů
Jenže to je chyba distribuce. Zrovna Debian se snaží mít vlastní skripty na všechno. Takže, zejména v počátcích přechodu na systemd, tam byly helpery, které se snažily ze service volat systemctl a naopak. Ne vždy to zafungovalo a zejména enable / disable (update-rc.d) nefungovalo snad vůbec.
Ano, řešením bylo tyto věci co nejdřív odinstalovat a používat výhradně systemd příkazy, ale to určitě není správné, pokud vás distribuce v dokumentaci nabádá používat její příkazy.
"...ale je jisté, že predstavuje skutečně určitý zlom a přerod od Unixu k něčemu jinému."
S tym suhlasim, otazne je, do akej miery je Linux stale "Unix-like".
"Linux is a family of open source Unix-like operating systems ...."
https://en.wikipedia.org/wiki/Linux
@klokan Je skupina lidí, kteří si pořád stěžují na problémy se systemd, a pak je skupina těch, kteří na žádný takový problém nenarazili. Nemám na to žádná data ale připadá mi dost možné, že k těm problémům dochází, když se člověk snaží i po zavedení systemd dál používat systém v unixovém stylu, tj. spravovat služby pomocí skriptů, nastavovat síť pomocí ifconfig nebo ip atd
nedavne priklady z praxe...
1. pouzival sem net.ifnames=0 a mel udev pravidlo s max adresama pro ethX pojmenovani 10x sitovek, muzem rict ze jsem to pouzival "postaru" (i kdyz parametr je "moderni a oficialni"), po nejake SW aktualizaci(systemd ci systemd-udev) to prestalo fungovat, musel sem net.ifnames=0 prekonfigurovat to cele (bond + bridge) na silene-nesmyslne-generovany-moderni-panazvy...
2. na jinem streoji sem NEpouzival net.ifnames=0, v stroji byla pouze 1x LAN co mela ten silene-nesmyslne-generovany-moderni-panazev kterej mel garantovat ze jmeno bude pro danou sitovku vzdy stejnej, zakaznik do stroje pridal SATA radic a stroj nebyl ze site dostupnej, nasledne sem zjistit ze se sitovce vygeneroval JINEJ nazev, vyndal SATA radic, sitovka dostala puvodni nazev a v siti byla, takze sem zmenil na novy nazev v konfiguraci, vypnul stroj, pridal se SATA radic, zapnul a sitove dostupne bylo... takhle si ale nepredstavuju nejake vylepseni ktere se chova hure nez pred systemd "genialnima panazvama"...
@k3dar
Nemusíš používat net.ifnames=0 ani udev. Je možnost si jméno iface nastavit přímo v systemd. A ty iface si můžeš matchnout nejen pomocí MAC, ale i podle jiných atributů.
Jak píšu v tom odkazovaném článku, tohle jsou věci, o kterých se bohužel příliš nepíše a lidi potom vymýšlejí různé nesmyslné postupy, přitom to má elegantní řešení.
Já zase dávám přednost tomu, když můžu spravovat věci sám a sám si určit co, kdy a jak poběží. Kdybych chtěl systém, který neprůhledně dělá "pod povrchem" co si sám zamane a kdy si zamane, navíc se neustále mění pod rukama, tak bych používal Windows. Jenže to nechci a proto jsem přešel k Linuxu a proto nepoužívám systemd.
Diky tomu, ze si AIX udelal poradek nekde jinde, nemusi resit problemy jako soucast init-u.
Jasně, nefunkční sysvinit a vždy funkční systemd. Zrovna dneska na Twitteru:
https://twitter.com/JirkaChadima/status/1174634408231473152
A takových věcí je plný Internet.
To víme, že je takových věcí plný internet, ale nikdo jim nebude věnovat pozornost, protože to je jen výkřik do tmy. Není tam ani napsané co se vlastně stalo, takže není možné říct, zda to je chyba systemd a nebo toho člověka, který si v každém postu na Twitteru na něco stěžuje dost svérázným způsobem.
> "systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak.
Ne, systemdmagie znamená, že mi došel kinedryl a další paletu kupovat nehodlám.
> To ze systemd integruje spoustu veci je trochu blby z hlediska politiky, protoze hromadi zodpovednost.
Není to trochu blbý, je to hodně blbý. Korunu tomu nasazuje arogance vývojářů.
> "systemdmagie" znamena, ze to funguje, ale nenastudoval jsem si proc a jak
dobrá ... a teď do reality
init se má starat o nahazování a shazování služeb
Proč se ale proboha stará o DNS a NTP? To má nechat systému nebo příslušnému démonu.
SSH v systemd je úplná hovadina a už.loginy přes init démona ... škoda slov.
To co je předváděno v systemd je vlastně to samé co je velká slabina Windows - monolitická struktura na které vše stojí a padá.
Asi je na čase se trochu vzdělat, než psát blbosti: https://www.youtube.com/watch?v=o_AIw9bGogo
Já systemd na většině strojů používám a o DNS ani NTP se mi nestará. O dané věci se starají programy z daného balíku, které jsou ale oddělené a můžeš je nepoužívat (na Debianu je dokonce jejich nepoužití default, alespoň v minimální instalaci). DNS mám jako veřejný resolver odkázaný v ručně napsaném /etc/resolv.conf a na NTP mám někde openntpd, někde ručně spouštěné ntpdate; systemd-resolvněco ani systemd-timesyncd mi nikde neběží. (pozn. tohle není obhajoba systemd, osobně mi přijde z různých důvodů špatný (naštěstí se většina z nich postupně zlepšuje), ale když chceš kritizovat, bylo by dobré dělat to podle skutečnosti)
> v základu řeší spoustu věcí co se v init.d dělali špatně nebo nešli vůbec dořešit.
Tak moment, v init.d (sysvinit) měl člověk shell, a ten je - pokud se nepletu - Turingovsky úplný. Co za problémy nešly dořešit v sysvinit? Neumím si to představit...
Na druhou stranu je systemd překomplikovaný systém, který mění léta zaběhlé defaulty, živí se na parametrech jádra, používá přinejmenším zavádějící pojmy v konfiguraci...
V legacy initech nemůžeš uhlídat procesy. (Teda můžeš - stačí si dopsat něco jako systemd.) To samé závislosti.
Stačí se podívat jaký chlív ty scripty bývaly.
(Jinak ta otázka je samozřejmě stejně dobře položená jako otázka, co nejde napsat v brainfucku.)
21. 9. 2019, 12:27 editováno autorem komentáře
Problém systemd je, že odpůrci se snaží argumentovat, ale ve výsledku předkládají nesmysly.
překomplikovaný systém - Vždyť to je jen nějaké hloupé video.
zaběhlé defaulty - Neexistuje něco jako zaběhlý default a v tomto případě se podle mě systemd chová lépe než jiné inity
živí se na parametrech jádra - Nakonec to bylo vyřešeno.
používá přinejmenším zavádějící pojmy v konfiguraci - Tohle asi není úplně přesně popsaný, protože ten uživatel použil nevalidní username. xinted mu to sežral a systemd ne.
> překomplikovaný systém - Vždyť to je jen nějaké hloupé video.
Ano, a s touhle logikou je systemd jen hromada hloupého zdrojového kódu. Tady už snad ani nemá smysl se dál bavit. Ale pro případ že bych si to vyložil stoprocentně blbě - to video hezky ilustruje, co všechno systemd nabaluje na init.
> zaběhlé defaulty - Neexistuje něco jako zaběhlý default a v tomto případě se podle mě systemd chová lépe než jiné inity
Něco jako zaběhlý default zcela jasně existuje. Například roky nepřítomnost nějakého "fail" parametru v fstab znamenala, že když daný disk nejde připojit, jede se dál (tedy "výchozí" nofail). Systemd to překopal, z podlahy vyrobil strop a všechny disky jsou ve "fail" režimu. Tadá, fakjů.
> živí se na parametrech jádra - Nakonec to bylo vyřešeno.
Ano, nakonec. Nakonec jsme se zbavili i komunismu. To nic nemění na tom, že příčetný vývojář by takový kód neměl napsat a příčetný správce změnu začlenit.
> používá přinejmenším zavádějící pojmy v konfiguraci - Tohle asi není úplně přesně popsaný, protože ten uživatel použil nevalidní username. xinted mu to sežral a systemd ne.
Když do konfigurace napíšu "user = někdo", očekávám, že ta služba poběží pod uživatelem "někdo" a pokud to z jakéhokoliv důvodu nepůjde, tak se nic nespustí a já dostanu vynadáno chybovým hlášením.
Rozhodně neočekávám, že "když to nepůjde, tak se username zkusí převést na user ID a služba se nakonec spustí pod tím".
Nehledě na to, že podle POSIXu (cituji):
3.437 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.
A to je právě hezký příklad překomplikovanosti systemd: proč ten kolos musí určovat, jestli je username validní - pokud takový uživatel existuje, je validní, pokud neexistuje, není to chyba validního username, ale chyba neexistujícího uživatele.
I když Linux není Unix a není POSIXem vázaný, základní linuxové nástroje (useradd, adduser) dovolí takového uživatele vytvořit. Ale existující ve světě systemd neznamená validní...?
Navíc viz vyjádření vrchního diktátora systemd, ve kterém zcela jasně nerozumí základům množin... Pokud má být unitfile přenositelný mezi liberálními a konzervativními distribucemi, neměl by systemd uvalovat žádná další pravidla nad rámec té nejliberálnější distribuce. Protože jinak přijde chvíle, kdy unita zařve (a ještě zařve takhle nesmyslně hloupě).
Ještě stále mojí snahu o argumentaci považuješ za nesmysl?
Tak mi konkrétně řekni, co by se rozbilo u chování "user existuje == user je validní volbou, user neexistuje == není validní volbou". Stále nechápu, proč si tam systemd musí cpát tu mezivrstvu, která rozhodne, jestli jde o "správné" uživatelské jméno. A tvé důkazy tvrzením na tom sotva něco změní...
Ked uz zase kopeme do toho mrtveho kona...
User moze byt bud username, alebo UID. Kedze systemd ti nevidi do hlavy, ktore si myslel, ked si to zadaval, tak ked dany string zacina numerickou hodnou, tak je to UID.
Manpage pre useradd hovori:
Usernames must start with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]?
Kedze si shadow-utils niektore distribucie opatchovali, aby bolo mozne vytvorit usera s numerickym username, tak si mali opatchovat aj systemd. Ziadny upstream predsa nemoze pocitat s tym, ze niekde nejaky dowstream urobi koninu a cele sa to rozbije. Ked uz robia svojsku integraciu, maju ju dotiahnut dokonca.