Proč jsou všichni proti systemd?

[Mirek Prýmek]

Upstart je 100x horsi ako SystemD.

Ta statistika není o tom, co je horší, ale v čem je hlášeno víc chyb.

[Reklama]

[ByCzech]

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.

[tnr]

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

[j]

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.

[JardaP .]

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.

[Reklama]

[Mirek Prýmek]

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

[j]

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.

[JardaP .]

Nesmysl. Kernel bude z linuxovych dister vypusten, protoze by zbytecne duplikoval funkcionalitu systemd.

[MarSik]

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.

[Mirek Prýmek]

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?!

[j]

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.

[Lama]

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.

[BoneFlute]

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.

[Viky]

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?

[j]

...

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.