ConsoleKit? :D
To, že systemd něco nahradí, snad neznamená, že to přestane existovat, ne? Závislosti definují vývojáři, pokud chcete jiné, tak si asi budete muset sehnat vývojáře, kteří také nestojí o systemd. Pokud vím, tak takových projektů je několik (třeba Devuan), ale nějak trpí nedostatkem aktivních lidí a peněz.
Vyvojari vyvijeji s ohledem na majoritni distra, hlavne ta komercni. Ta udelal uchylne rozhodnuti prejit na systemd, ktery neni pouhou volitelnou komponentou, ale komponentou nevystrnaditelnou a ktera se vnucuje jako zavislost jinych veci, protoze ty je nutno predelat tak, aby s tim krapem fungovaly. Takze se rozjel vlak, kdy vse pujde do prdele a Poettering se stane tak nenahraditelnym, ze snad jednou bude i prezidentem Zeme.
Třeba takový Debian či Arch jsou komerční distra jak noha…
Jako závislost čeho se vnucuje? GNOME na systemd přešel dobrovolně, KDE na systemd nezávisí. Oboje bylo svobodné rozhodnutí jeho vývojářů. Screen a tmux špatně používají PAM sessions (spoléhají se na to, že sessions se neuklízí, protože to dodnes nikdo neimplementoval), pokud si to opraví, tak budou fungovat správně i se systemd ve výchozím nastavení. Bez jakékoliv závislosti na systemd.
A jen tak mimochodem:
sten@kink ~ $ ldd /usr/bin/screen
linux-vdso.so.1 (0x00007ffed19e1000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f1f03a60000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f1f03829000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f1f03619000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f0326e000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f1f03048000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f02e44000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f03c8a000)
login a jak dobře to fungovalo.Hmm, co mi to jen připomíná?
PAM byl prostě dobrý nápad. Nikdo z nás nechce, aby věci ustrnuly na místě. Rozumné změny jsou nutné.
Systemd je příšerný nápad, který přináší spoustu problémů hlavně tím, že nechce být pouhým init systémem, ale chce pohltit takřka vše. Pokud by se snažil pouze o to, co měl dělat původně, nikomu by příliš nevadil.
Mimochodem s PAM přišel SUN, pokud vím(1994 nebo 1995). To jak dobrý nápad to byl dokazuje nepřímo i to, že byl vcelku bez keců přijat třeba do FreeBSD.
Vaší manipulativní demagogickou exhibici nechápu. Aha... Poeteringovec... Jasné...
Systemd byl od počátku projektován jako náhrada přinejmenším initu, mountu a inetd. Měl prakticky stejné cíle, ke kterým vývojem dospěl upstart, že by bylo potřeba spojit v novém initu, ale který je nikdy pořádně neimplementoval (hlavně z toho důvodu, že byl zpočátku napsán právě jen jako náhrada initu, takže by to znamenalo většinu přepsat).
FreeBSD zřejmě nikdy nebude ani zvažovat přijímání systemd, protože systemd je závislý na vlastnostech linuxového jádra, které FreeBSD prostě nemá a mít nechce. Přijetí PAM ve FreeBSD rozhodně nebylo bez keců, což byl i důvod, proč si nakonec napsali vlastní implementaci PAMu (OpenPAM).
Při každé větší změně se vedou diskuse. V případě PAM na FreeBSD to nebylo zdaleka takové jako v případě systemd. Důležité je, že byl přijat na základě technických argumentů nejen lidmi v centru dění, ale poměrně rychle i uživateli. V případě BSD projektů je každá taková událost důkazem kvality.
Závislost systemd na jednom konkrétním jádře OS - to také vypovídá...
*BSD je prostě Unix v pravém slova smyslu. Z Linuxových distribucí se bohužel stává břečka. Nikdy nevynikaly extrémní péčí o kvalitu ani nějakou superkoncepčností, ale pořád to šlo - ty komerční a třeba i CentOS nebo Debian bývaly dobrá volba... To je minulost díky i takovým mlamojům jako jste vy.
Škoda, ale mnohdy se dá použít právě třeba FreeBSD. Vývojářům patří velký dík.
U mě jde spíš o to, jakým způsobem systemd prosazuje.
Jak jsem psal, kdyby to bylo stylem, že by si to implementovalo své vlastní věci (já používám timesyncd tam, kde o nic nejde, na ostrých serverech to musíme mít v souhlasu se státním etalonem, takže tam mám ntp pro lepší monitoring; networkd - protože interfaces v Debianu se mi nelíbí a NM nefunguje; resolved; nspawn - pro mě vynikající nástroj; timer vedle cronu atd.), tak neřeknu ani popel. Tam kde chci si to nastavím a použiji. Tam, kde nechci, tak to nepoužiji. Prostě, kdyby systemd byl jedním ze 40tis. balíčků v repu, tak jsem rád, že tam je, protože se mi může hodit (a hodí se mi).
Ale třeba už jen ten bugreport tmux ukazuje co je špatně. Tam je totiž špatně úplně všechno. Nějaký zabugovaný program si po sobě neuklízí procesy. Normální by bylo opravit ten program. Ne, místo toho LP napadne, že by bylo skvělé zavést střílení procesů při odhlášení. Jenže toto "řešení" něco rozbije, tak je nutné tlačit na autory toho něčeho. Takže tlak na opravu toho původního zabugovaného programu slábne.
Tohle se v bledě modrém stalo s ext4. Některé blbě napsané programy při pádu stroje ztrácely své nastavení. Dřív na ext3 se to, údajně, nestávalo. Důvod, proč se to nestávalo bylo výchozí nastavení žurnálování na ordered, které zajišťovalo, že při změně metadat se nejdříve uloží data a potom metadata. Debilně napsané programy toho zneužívali tak, že místo volání (f)(data)sync při změně konfigurace prostě zavolali rename (změna metadat). Tohle fungovalo jen a pouze na ext3 a jen a pouze v nějakém (bohužel zrovna defaultním) nastavení. Samozřejmě, správným řešením by bylo opravit ty vadné programy. Co se ale nestalo, ext4 dostala heuristiku na rozpoznávání vadných programů, aby se k nim chovala stejně jako ext3 ordered. Od té doby ext4 nepoužívám. Čím dřív se odhalí vadné programy, tím lépe, alespoň vím, co nepožívat.
Kdysi jsem se tu s Jirsákem hádal o tom, jaká je blbost mít (snadnou) možnost restart on failure. A došlo na moje slova, spousta vývojářů přestala řešit, proč jejich program padá, protože to lze triviálně restartovat.
Ale mě už je to jedno. Přecházím (no, vlastně je hotovo) na FreeBSD. Jednak mě k tomu konečně dokopal kámoš, taky je to trivka (pro linux admina je to prostě jen jiná distribuce) a jedna z věcí, která mě k tomu také dokopala je případ, který se mi stal před několika měsíci. Hledal jsem program na něco (binární diff) našel jsem bsdiff. No a v manu (resp. na webu k tomu má papír) se rozepisoval v O notaci o složitosti a dokonce velmi přesně o paměťové náročnosti. Potom jsem si vzpomněl, že takto nějak jsem začínal s linuxem. V man stránkách programů (třeba souborové db) byl vzorec na byte přesně, kolik daná data budou zabírat apod. Tohle už tam dneska není. A od lidí skákajících do stropu z restart on failure se toho ani nedočkáme.
Nějaký zabugovaný program si po sobě neuklízí procesy. Normální by bylo opravit ten program. Ne, místo toho LP napadne, že by bylo skvělé zavést střílení procesů při odhlášení. Jenže toto "řešení" něco rozbije, tak je nutné tlačit na autory toho něčeho. Takže tlak na opravu toho původního zabugovaného programu slábne.
Původní chyba nebyl zabugovaný program, ale problém s tím, jak funguje grafické sezení. To nemá řídicí terminál, takže když se ukončí D-Bus, tak nikdo nemá jak procesům říct, že mají skončit. Dosud se to „řešilo“ tak, že se D-Bus nespouštěl v PAM session, což je ale hack, který ne úplně dobře funguje, protože programy poběží i po ukončení PAM session, což například uzavře ecryptfs, odpojí NFS a DAV automounty, zabije SSH agenta, odhlásí z domény či odebere oprávnění k některým zařízením. Anebo taky programy třeba nikdy neskončí. Což může snadno vést (a taky občas vede) ke ztrátám dat a velmi těžko odladitelným problémům.
tmux je v tomhle také rozbitý, protože se snaží přežít konec PAM session, opět s možnými následky výše. Všichni to ale dosud brali jako „samozřejmost“ a vymýšlely se na to workaroundy, aby to tak nějak, občas více, občas méně dobře fungovalo. Systemd pouze změnil to, že když PAM předpokládá, že ukončená session nezanechá běžící programy, tak to začal vynucovat. Vytkl bych to, jak radili, že by to tmux měl řešit, ale samotný problém je tu už poměrně dlouho a vyřešit by se měl.
Čím dřív se odhalí vadné programy, tím lépe, alespoň vím, co nepožívat.
A proto systemd udělalo, co udělalo ;-)
A došlo na moje slova, spousta vývojářů přestala řešit, proč jejich program padá, protože to lze triviálně restartovat.
Kteří vývojáři? Tohle dělá Apache přinejmenším od verze 2.0 a nevšiml jsem si, že by pády Apache nikdo neřešil.
Původní chyba nebyl zabugovaný program, ale problém s tím, jak funguje grafické sezení.
Takže nějaký program forknul nějaké potomky a je neschopný je ukončit? Nebo jak ještě vznikají procesy?
Tohle dělá Apache přinejmenším od verze 2.0 a nevšiml jsem si, že by pády Apache nikdo neřešil.
Co tím konkrétně myslíš? Workery? Ty se řídí konfigurací. Že se by se někdy ukončil root proces apache jsem si nikdy nevšiml (a vím to, protože mám na stovkách webserverů screen po dlouhé měsíce / roky a vidím tam pid apache v historii. Jinak to, že workeři mají nastavenou životnost (k vůli leakujícímu php) se mi samozřejmě také nelíbí.
Takže nějaký program forknul nějaké potomky a je neschopný je ukončit? Nebo jak ještě vznikají procesy?
Pokud nějaký z těch potomků forkne další potomky a skončí (což dělá třeba inicializační skript v KDE), tak ti potomci se přesunou pod init (PID 1) a původní proces se o nich nedozví.
Co tím konkrétně myslíš? Workery? Ty se řídí konfigurací. Že se by se někdy ukončil root proces apache jsem si nikdy nevšiml (a vím to, protože mám na stovkách webserverů screen po dlouhé měsíce / roky a vidím tam pid apache v historii. Jinak to, že workeři mají nastavenou životnost (k vůli leakujícímu php) se mi samozřejmě také nelíbí.
Přesně tak, myslím workery. Workeři se automaticky ukončují po nějaké době, ale taky můžou spadnou a root process je restartuje (chová se stejně jako systemd s Restart=always). Root proces padá výjimečně, ty padající chyby jsou nejčastěji v modulech zpracovávajících požadavky.
(což dělá třeba inicializační skript v KDE)
A nešlo by jej opravit?
Workeři se automaticky ukončují po nějaké době, ale taky můžou spadnou a root process je restartuje
No jasně, což je dané sračkami, co se na dnešním webu používají. (Jak jsem psal, nelíbí se mi to.) Svět webu je specifický, pro jistotu si ani nevybral well formed xml a místo toho prohlížeče raději odhadují, co přesně autor tím zkripleným html myslel. Toto bych spíš uváděl jako odstrašující případ, kam to vede, než jako "apache to dělá taky".
A nešlo by jej opravit?
Co by měl dělat? To, že se potomci přesouvají pod init, je úmyslná vlastnost Unixu. Ten skript může tak akorát zůstat viset, ale pořád by šlo jen o workaround, může z nějakého důvodu skončit ( killall sh, OOM, spadne, …) a problém je tu zpět. Navíc se to netýká jen toho skriptu, ale jakéhokoliv procesu, který spustí jiný a potom skončí, třeba správce souborů může spustit přehrávač videa a pak být uživatelem ukončen, a najednou přehrávač videa není v procesové hierarchii toho skriptu.
Toto bych spíš uváděl jako odstrašující případ, kam to vede, než jako "apache to dělá taky".
Moje argumentace byla, že to, že Apache restartuje padající workery, nemá za následek, že by byli workeři padající víc než jiné služby, protože by si autoři řekli, že ty pády nebudou řešit.
Co by měl dělat?
Nevím co by měl dělat, jsem admin, ne programátor. Když se podívám na strom procesů, tak je na pid 1 navázáné pouze to, co tam navázané být má (služby spouštěné při bootu). To znamená, že evidentně jde zařídit, aby proces měl pod kontrolou své potomky nebo aby o žádného potomka nepřišel. (Ano, je to takový důkaz nedůkaz realitou, ale i tak.)
Moje argumentace byla, že to, že Apache restartuje padající workery, nemá za následek, že by byli workeři padající víc než jiné služby, protože by si autoři řekli, že ty pády nebudou řešit.
No to je možné, asi jsou vývojáři apache více disciplinovaní, než prostě někdo z ulice. Viděl jsem mnoho příkladů, kdy vývojář používá restart jako na běžícím pásu.
To je totéž jako docker. Spousta lidí byla natěšená, jak díky dockeru nemusí řešit verze ničeho a prostě si tam dá co je jim libo - bez ohledu na bezpečnostní updaty). Ostatně admini jistě znají Java aplikace, které si s sebou tahají konkrétní verzi jre5.
Když se podívám na strom procesů, tak je na pid 1 navázáné pouze to, co tam navázané být má (služby spouštěné při bootu). To znamená, že evidentně jde zařídit, aby proces měl pod kontrolou své potomky nebo aby o žádného potomka nepřišel. (Ano, je to takový důkaz nedůkaz realitou, ale i tak.)
Ve FreeBSD je na to API procctl. Linux má pro podobný případ cgroups (které tedy neudržují strom, ale skupiny procesů). Což je právě to, co používá systemd pro správu sezení a co tmux neumí používat.
S tim PID1 je to docela ozehave...staci se podivat na kombinaci skriptu a cronu:
#ps -ef | grep 250
root 25011 928 0 09:57 ? 00:00:00 /usr/sbin/CRON -f
user 25012 25011 0 09:57 ? 00:00:00 /bin/sh -c /tmp/test.sh
user 25013 25012 0 09:57 ? 00:00:00 /bin/sh /tmp/test.sh
user 25014 25013 0 09:57 ? 00:00:00 /usr/bin/tail -f /var/log/syslog
#kill 25012
#ps -ef | grep 250
user 25013 1 0 09:57 ? 00:00:00 /bin/sh /tmp/test.sh
user 25014 25013 0 09:57 ? 00:00:00 /usr/bin/tail -f /var/log/syslog
Killnout 25011 se neda, takze dalsi ze stromu se da killnout 25012. Vysledkem jsou procesy pod PID1 jako rodic.
A vtipne je taky toto:
#ps -ef | grep 251
root 25138 928 0 10:07 ? 00:00:00 /usr/sbin/CRON -f
user 25139 25138 0 10:07 ? 00:00:00 /bin/sh -c /tmp/test.sh
user 25140 25139 0 10:07 ? 00:00:00 /bin/sh /tmp/test.sh
user 25141 25140 0 10:07 ? 00:00:00 /usr/bin/tail -f /var/log/syslog
#kill 25140
#ps -ef | grep 251
user 25141 1 0 10:07 ? 00:00:00 /usr/bin/tail -f /var/log/syslog
A tentokrat se toho killnulo vic, ale zustal posledni potomek :D Proste problem s tim, co zustane po killu, kdy nejde killnout rodic a nekillne se posledni potomek.
#cat test.sh
#!/bin/sh
/usr/bin/tail -f /var/log/syslog
Teď mluvíte o stavu se systemd? Jestli ano tak to se snaží systemd řešit svými timery a cron je legacy řešení, které je z pohledu systemd rozbité stejně jako před systemd.
Na druhou stranu já toto nepovažuji za bug, ale za dobře popsanou feature - tak se linux vždy choval, toto chování převzal od jiných unixů, a je na programátorovi, či administrátorovi aby si potomky ohlídal...
... Zrovna "tail -f" v tomto případě ničemu nevadí. Umře sám, hned jak se pokusí zapsat další novou řádku z /var/log/syslog do stdout. (Protože je ta pajpa z druhé strany už zavřená a on dostane SIGPIPE). Pokud to není ten případ, je potřeba opravit test.sh, aby se o své potomky staral rozumějším způsobem.
Jako admin s takovým chováním nemám problém, naopak se lépe dozvím, že bylo potřeba killnout test.sh bez ohledu na jeho potomky, což byla nepochybně výjmečná situace, a je potřeba odstranit její příčiny. Jako adminovi mi nedává žádný smysl řešit NÁSLEDKY výjmečné situace AUTOMATICKY. To většinou vede jen ke skrytí opravdových problémů.
Co ma delat jineho, kdyz nejlepsi argumenty jsou ty vymyslene?!
"Why Debian should default to systemd
Fedora, OpenSuSE, Arch and Mageia have already made the choice to use systemd, and it is getting excellent upstream support for a growing number of packages."
https://wiki.debian.org/Debate/initsystem/systemd
Tak hlavne nas nepodezirej, ze vam systemd nejak zavidime a tak vam ho neprejeme. Naopak, dejte si i za nas, aspon dvojitou porci.
Jiz jsi si mohl vsimnout, ze nase hlavni vyhrada je naopak v tom, ze vy nam systemd nutite. Az bude systemd zcela volitelna komponenta a ne neco, co se nasere vsude, vynuti zavislosti jinych soucasti na sobe samem a rozbije kompatibilitu s kde cim, nerekneme proti systemd ani popel, akorat se vam budeme smat a budeme si na vas ukazovat prstem. A mezitim si pockame, jestli se za deset let ze systemd nevyklube neco pouziteleho nebo jestli z nej nerupne nekomu v bedne tak, ze radsi napise neco rozumneho.
Jak se systemd sere všude? Jestli jsem si dobře všiml, tak změnu výchozího init systému pořád ještě rozhodují konkrétní distribuce a závislosti vývojáři konkrétních programů a Poettering rozhoduje jen o svých programech. Tak zkus přestat vnucovat ostatním, že musí dělat to, co chceš zrovna ty.