Vlákno názorů k článku Nebojte se systemd: zbývající typy jednotek od mog - my se systemd nebojíme, my ho v systému...

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.

Kretene, PAM nikdo normalni v systemu nema. Ze nejaky kokot neni schopen pri logoutu ukoncit sesnu enznamena, ze ma nekdo neco strilet. A ten kretenismus je jedinej duvod, proc to do systemd dali. Screen nic rozbityho nema a proto taky nic nehodlaji opravovat.

Kterou normální distribuci bez PAM používáš, ó moudrý j? A jak ti dobře ti to funguje, když na PAM závisí i udev či su?

A jen tak mimochodem:


sten@kink ~ $ ldd /usr/bin/screen
linux-vdso.so.1 (0x00007ffed1­9e1000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f1f03­a60000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f1f03­829000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f1f03­619000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f03­26e000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f1f03­048000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f02­e44000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f03­c8a000)


PAM má v systému spoustu let prakticky každý uživatel linuxového distra. Je to velmi užitečná věc. Přesně ten případ, kdy byla inovace velmi žádoucí a řešila reálné problémy.

1. PAM prosadil Red Hat.
2. PAM rozbil to, jak do té doby fungovala autentizace. Všechny aplikace, které chtěly ověřovat uživatele či hesla, se musely přepsat, včetně GNU screen.
3. PAM není unixový ani POSIX.
4. PAM nejde z distribuce snadno vykopat.
5. PAM je sice modulární, ale nejde používat jen některé moduly bez napojení celého systému na PAM.
6. 25 let se používaly soubory a 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.

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.

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=alwa­ys). Root proces padá výjimečně, ty padající chyby jsou nejčastěji v modulech zpracovávajících požadavky.

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.

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

Zajímavé, že tohle jako důvod nezmiňují ti, co o zavedení systemd rozhodovali v Archu či Debianu (u Debianu to byl akorát argument, proč přejít na systemd místo na upstart, ne proč odejít od sysvinitu). Že by sis to vymyslel? :-)