HOVD 2019 - Kedvenc init rendszer

Címkék

Szavazz az alábbi kategóriákban! Kedvenc ...

busybox
4% (32 szavazat)
nosh
0% (1 szavazat)
openrc
8% (66 szavazat)
pies
0% (0 szavazat)
procd
0% (2 szavazat)
runit
3% (22 szavazat)
s6
1% (8 szavazat)
systemd
58% (496 szavazat)
sysvinit
26% (219 szavazat)
uinit
0% (3 szavazat)
Összes szavazat: 849

Hozzászólások

mint init rendszer tetszik a systemd. de az, hogy lassan mindenbe belenyul amihez semmi koze (pl. dns) az mar nem.

Mint cloudos fejleszto baromi kenyelmes dolgok vannak benne, amikor mondjuk egy kesz rendszert kapunk, amihez hozza kell igazitani valamit. Pl ha ezt szeretnem, hogy X elott meg lefusson valami, es mondjuk nem erdekel, hogy sikeres volt-e a futas attol meg X induljon el. Ez systemd-ben egy ket soros file. Vagy mondjuk ha Y ujraindul, induljon ujra Z is, vagy masik user neveben, ... nagyon hosszu a lista.

Szerintem csak a szavazás van szerencsétlenül kiírva ezzel a „kedvenc” jelzővel. 200+ embernek nem kedvenc egyáltalán, hanem csak ezt használják. Ezzel jön a disztró, amit használnak, használják, ami be van építve, nem akarnak széllel szemben hugyozni. Biztos vagyok benne, hogy szeretni nem szeretik ennyien. Rá vannak kényszerülve a használatára, egyszerűen csak használják.

Nekem az initrendszer egyébként mindegy, csak ne systemd legyen, és lehetőleg tudja a szolgáltatásokat párhuzamosan betölteni a gyorsabb boot érdekében. Most vagyok átállóban Arch + systemd kombóról Gentoo + openrc kombóra. Egy szemléletes példa: Arch alaprendszer boot után konzolban 100 MB memóriát eszik. Gentoo openrc-vel 29 megát! Ennél többet nem is kell mondani a systemd-ről, nem szorul egyszerűen kommentre.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Egyáltalán nem. Az igaz, hogy véleményem szerint szar, de én pragmatikusan közelítem meg a helyzetet. Aki használ olyan szoftvert, ami annyira dependel rá, annál teljesen megértem, hogy nem akar alternatív initrendszerrel szívni, hanem használja a systemd-t, főleg ha már úgyis default azzal érkezik a disztrója. Ebben semmi hibát nem is látok, ha én lennék ebben a helyzetben, akkor talán még én is így csinálnám. De nekem azért az egy kicsit erős, hogy mindjárt érzelmileg is „kedvenc”. Nem is értem mit lehet rajta szeretni. Főleg ez initrendszeren, aminek csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit. Nekem ez kicsit furcsa fetisizmusnak tűnik, ha valaki ebbe van beleszerelmesedve. Azért is írtam, hogy nekem az initrendszer elvileg mindegy, egyiket se szeretem, használom azt, ami nekem jobbnak, kevésbé bloatnak tűnik, és törekedek rá, hogy lehetőleg az ne systemd legyen. Ennyi, nem kell ebbe túl sokat belelátni.

Azt még el is hiszem egyébként pár perverz emberről, hogy kifejezetten rajongója a systemd-nek, de 200+ szavazónál erősen kétlem.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

"Nem is értem mit lehet rajta szeretni" a hozzaszolasod felett is kifejtettem. a rugalmassagat es testreszabhatosagt lehet szeretni pl.

"aminek csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit" igen, ami nem 1 dimenzios tortenet, hanem leteznek fuggosegek, egyutt ujrainditando dolgok, service inditast megelozo lepesek, stb.

"pár perverz emberről" ez nem perverzio kerdese. Amikor valami config management cuccal automatizalni kell rendszerek uzemelteteset, akkor baromira kapora jon, hogy distro fuggetlenul leteszek egy service update filet a megadott helyre, es full controlom van a serviceim felett anelkul, hogy egyetlen script filet is megvaltoztatnek.

 

Pont a multkor futottam bele egy ilyenbe, Csinaltunk egy egyszer futo servicet, aminek Docker daemon utan kellett elindulnia, ujra kellett indulnia amikor a docker ujraindult, raadasul ujraindulas kozben ki kellett takaritani valamit az elozo futasbol, plusz egy 3rd party servicehez is csatlakozott, szoval ha nem sikerult neki elindulnia, akkor tobbszor is meg kellett probalni. Es miutan sikeresen lefutott, valamilyen formaban perzisztalni kellett, hogy lefutott. Ezt kb 5 perc alatt osszehoztuk egy unit fajlban egy sor script nelkul (es egy sor script teszt nelkul). Kb. After, Requires, One Shot, ExecStartPre, Restart, RemainAfterExit. Raadasul ha valaki megis meg akarna valtoztatni, csak overrideolja amit akar.

csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit

Nem csak az a dolga. Függőségek, hibakezelés - újrainduljon? Hányszor? Time out? -, különféle timer-ek kezelése, például bekapcsolás után valamennyi idővel indítson automatikus upgrade-et, illetve heti egyszer legyen fstrim, és így tovább. Nem olyan rossz az, csak szerintem nem ismered. Arra is van lehetőség, hogy felülírsz unit file-t úgy, hogy nem szerkeszted a default-ot, így egy frissítés nem rontja el, de azt is lehet, hogy a default-hoz képest kiegészítéseket írsz hozzá.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, akkor fogalmazzuk úgy át, rendben betöltse a rendszer elemeit. Ezeket, amiket írtál, tudja az OpenRC is. Egyébként magával az initrészével a systemd-nek még nem is lenne akkora bajom, a gond az, hogy sok mindent saját szakállra dönt el, meg egy csomó bloat hozzá van csomagolva már, rég nem csak egy initrendszer, egyfajta user space mini OS lett. Semmi baj nem lenne vele, ha megmaradt volna initrendszernek, és nem dependelnek rá mindent, nem kényszerítik be minden disztróba. Tőlem elférne, ha csak egy +1 alternatíva lenne.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nagyjából emiatt nem szavaztam ebben a kategóriában. Jelenleg minden gépemen systemd fut, mert ez a disztribúció alap init rendszer (Debian, Arch), viszont nem mondanám, hogy kedvenc lenne. A systemd alap elgondolása tetszik, az, hogy magába olvasztott egy csomó olyan funkciót, ami nem egy init rendszer feladata, az nagyon nem. A sysvinitet hasznátam a maga összes problémájával, az upstartról nem győztem elmenekülni, a többit viszont nem, vagy csak érintőlegesen ismerem. De szerintem más is képes eldönteni a saját szempontrendszere alapján, hogy szavaz-e, és hogy mire. Ahogy a többi kategóriában is.

A systemd alap elgondolása tetszik, az, hogy magába olvasztott egy csomó olyan funkciót, ami nem egy init rendszer feladata, az nagyon nem.

A probléma az, hogy a systemd-re mint init rendszerre hivatkozik mindenki. Ha az volna jogos volna az érv, hogy túl sokat tud egy init rendszerhez. De nem az. Ezt írják róla a freedesktop.org-on: "systemd is a suite of basic building blocks for a Linux system."

Talán sántít a hasonlat, de az ablakkezelők -> asztali környezetek kapcsolatát lehetne idevenni. Egy asztali környezet jóval több dolgot tud és csinál mint csak egy WM. És ez nem is baj. 

én próbáltam már:

  • a runit szerintem hányás, folyamatos fájdalom :)
  • az s6 egyébként a kedvenc listám második helyén van, mert át van gondolva, jó értelemben vett minimalista, és kudos a chainloading startégiáért, szóval kalap le a benne levő engineeringért (még ha személy szerint nem mindent gondolok annyira fekete-fehérnek, mint emberünk), de azért használni nem szeretem.
  • Openrcnek anno a wikipédia oldalán elakadtam, már nem emlékeztem miért. Ránéztem megint, gondolom azért, mert a példa samba service 62 két sornyi shell script rajta. Szóval n+1edik randomdistro sysvinit fölé tákolt shellhalomjának látszik, a pötyi bácsinak meg igaza van a deklaratív konfig fileokkal. Komolyan, ilyeneket kellene beleírni?
    # szabványos újraindító függvény
    reload() {
    	${my_service_PRE}
    	signal_do reload
    }
    
  • Többit nem néztem, az utolsót most jól megnéztem, bazmeg javascript.

Szerintem simán használni ezeket mind egyszerű. Be is tenne, ha már az is bonyolult lenne, hogy foobar start|stop|restart vagy valami alternatív ige, mert az jó. Igazából szerintem mindnek van service wrappere, szóval ha 92 körül megtanultad, hogy "service akármi restart", akkor az most is jó :D

A systemd valóban felrúg még egy két dolgot: leállíthatatlan waiting for stop job, mert a magic sysreq nem jó, journalctl defaultból, skandallum, és még a nohupos otthagyott random futó szarokat is kitakarítja, ha kilép a shell, blaszfémia (az, hogy helyette ad normális módot arra, hogy lehessen tudni, mi a fenét hagyott ott valaki oldalágon odabaszva az initnek, hogy majd csinálj vele valamit, az meg ugye senkit nem érdekel), a szélesebb feature készlet miatt, de azért -- szerintem -- messze nem targédia.

Az openrcvel ránézésre annyi a bajom, hogy n+1-dik próbálkozás arra nézve, hogy adjon egy shell toolingot ezeknek a kezelésére. Még az is lehet, hogy jobb (végül is, volt miből levonni a konzekvenciákat), de igazából a nagy hozzáadott értéket azért nem látom, és az biztos, hogy nem akarok 60 soros scriptet írni ahhoz, hogy el lehessen indítani, meg le lehessen állítani egy rohadt daemont. Ráadásul az egyik fele olyan, hogy egy jobb reggelen szebbet "készítek" még a kv előtt ( eval cmd_exec=\$${daemon}_${signal} pfejj) , a másik fele meg boilerplate. És ahol a rendszer része az, hogy boilerplate kell, ott minden jólelkű programozónál el kellene kezdeni villogni a piros lámpának fejben, hogy nagyon nem sikerült eltalálni az absztrakciót.

Tök érdekes , amit írsz. Nekem mint usernek kb. úgy jött le a dolog, hogy használtam disztrokat sysvinit-tel, és hát igen értem meg minden, de valahogy az openrc volt a (user oldalról) a legáttekintehtőbb és a függőségkezelés miatt a legegyszerűbb is. Aztán jött a systemd és csak az a kérdés merült fel bennem, hogy "Mi ez a kaotikus szar?"

Ma úgy látom, hogy a systemd által betöltött (vagy betölteni kavánt) funkcionalitásra nyilvánvalóan szükség van, és itt nem elsősorban az init rendszerre gondolok. De az is nyilvánvaló, hogy a systemd ezt távolról sem jól valósítja meg.

Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti. A jelenelgi systemd konglomerátum így ebben a formában ezekkel a hibákkal és ilyen fejlesztési filozófiával tényleg egy jelentős problémává nőtte ki magát.

> Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti.

Az s6 kb. ezt csinálja, csak nem önti bele az egészet az initbe, szétbontható az egész, úgy rakod össze, ahogy neked jó, amúgy UNIX-osan és teszi ezt hordozható módon, tehát minden POSIX rendszerre jó és nem egyetlen bloated Linux-only blob az egész. De ahogy nézem a bra-ket által említett nosh is hasonló koncepciójú, bár ott csak a BSD-ket és a Linuxot említi a szerző, mint célplatformot.

Ránéztem, elég ígéretes. Ahogy így elnéztem van legalább 2 arch linux variáns, ami csak arra jött létre, hogy alternatív init rendszert nyújtson. A kipróbálásig nem jutottam, de azért elvileg van kész megoldás, ha a mainstream mégis szabadulna a systemd-től. Igen tudom, hogy AUR-ból jelenleg is több opció elérhető, de azért ezekhez a dokumentáció enyhén szólva is hiányos.

A doksikat a fejlesztő(k) oldalán kell keresni, az s6-nak pl. elég jó doksija van. Arra viszont egy darabig ne számítsunk, hogy a systemdtől annyira szabadulna a mainstream; tavaly még csak-csak rá lehetett mondani, hogy egyenlő arányban vannak az ellenzők és a támogatók, hiszen 1 nyamvadt szavazaton múlott, hogy a systemd-nek abszolút többsége lett, de most annak ellenére, hogy többen szavaztak, most egyértelműen abszolút többséggel vezet eddig a systemd, tehát a helyzet csak romlott... Kiváncsi leszek holnap a Debianosok szavazásának eredményére.

Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti.

Az ugye megvan, hogy minden systemd-* (meg maga a systemd) alapvetően D-Buson kínál API-t a nagyvilágnak, ami egy introspektálható, standardizált megoldás: vagyis annyi a dolgod, hogy fogod lekéred az implementált interfészt, írsz rá egy implementációt, és öröm és boldogság.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Javíts ki, ha tévedek, de én úgy tudom, hogy a systemd nem egyszerűen magától a D-Bus protokolltól függ, hanem egészen konkrétan a kdbus D-Bus implementációtól, ami nem volt része a kernelnek és még javában folytak a viták a kernelfejlesztők között, hogy melyik bus alternatíva váltsa a régi BUS1-et és a kdbus finoman szólva sem tartozott a favoritok közé, de ekkor a FreeDesktop Team közölte, hogy ha systemd-t akarnak futtatni, akkor ez és kész. És mivel akkorra már a disztrók többsége systemd-függő volt, a kernelfejlesztők lenyelték a békát és így sikerült egy újabb FreeDesktop komponenstől függővé tenni az egész Linux ökoszisztémát.

Mert -- egyébként együtt a mozzilával, csak őket én kevésbé látom fajsúlyosnak, a google sokkal egyszerűbben tolja le mindenki torkán a saját elképzelését a világról -- implementálták a supportot bele a böngészőbe, úgy, hogy hát majd használja a rendszer névfeloldását, ha akarja, meg amikor akarja, egyébként meg nem. Ez szerintem egy rendkívül káros gyakorlat. Félre ne érts, én is írtam már olyan kódot, ami maga intézte a névfeloldást bizonyos esetekben, de az egy speciális eset, egy általános kliensprogramban ilyet elkövetni finoman szólva is nem elegáns.

Bár nagyon érintőlegesen néztem még a témát, de úgy tűnik, hogy vicces módon az MSnek sikerült ezt oda tenni, ahova való: bele a system resolverbe. Nembaj, majd pöttering megírja a resolvedbe, és lehet még jobban utálni :D

Szóval nem magával a protokollal van baj, hanem azzal, hogy hova tették. (Illetve azt még szintén meg kéne néznem, hogy egyébként mi a fenétől jobb ez bármivel, mind a dnssec)

amihez semmi koze (pl. dns) az mar nem

Jajúristen, szemét systemd, hogy a fejlesztője kihasználva, hogy csomó plumbing már meg van, így gyorsan összeüthet egy resolvert, megcsinálta a systemd-resolved-ot :( Persze hogy a használatához többször kell opt-inelni (csomag feltelepítése, szolgáltatás engedélyezése, nsswitch-be és/vagy resolv.conf-ba felvitele), az már egy olyan apróság, amivel nem foglalkozunk...

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

masfel honapja telepitett centos7-en "csak" ezek futnak by default:

root          1      0  0  2019 ?        00:31:28 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
root        386      1  0  2019 ?        01:02:33 /usr/lib/systemd/systemd-journald
root        413      1  0  2019 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root        565      1  0  2019 ?        00:01:55 /usr/lib/systemd/systemd-logind

resolved nincs. de udevd? logind? wtfd?

itt egy par napja telepitett ubi 18.04 lts server ps-e:

root       422     1  0 Jan02 ?        00:00:01 /lib/systemd/systemd-journald
root       457     1  0 Jan02 ?        00:00:05 /lib/systemd/systemd-udevd
systemd+   728     1  0 Jan02 ?        00:00:00 /lib/systemd/systemd-timesyncd
systemd+   950     1  0 Jan02 ?        00:00:00 /lib/systemd/systemd-networkd
systemd+   973     1  0 Jan02 ?        00:00:00 /lib/systemd/systemd-resolved
message+  1121     1  0 Jan02 ?        00:00:31 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root      1236     1  0 Jan02 ?        00:00:15 /lib/systemd/systemd-logind
root      3047     1  0 09:47 ?        00:00:00 /lib/systemd/systemd --user

f31 -en nem latom ezeket (nem friss install, upgrade).

chrony az ajanlott NTP.
Networkmanager az ajanlott network config.
systemd-resolved nincs ajanlas, unbound gyakran hasznalat.

systemd-machined viszont van, aminek nem sok ertelmet latom.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Linux Mint 19 (~Ubuntu 18.04). Nem kértem, hogy telepítse, nem nyúltam hozzá, és ott figyel a "vendor preset: enabled" is:
 

$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: active (running) since [...]


$ lsb_release -a
No LSB modules are available.
Distributor ID:    LinuxMint
Description:    Linux Mint 19.3 Tricia
Release:    19.3
Codename:    tricia
$

megneztem egy nemreg 18-ra upgradelt 16.04-et is amin 1000% hogy nem volt resolvd az upgrade elott, es most azon is van, szerencsere a resolv.conf-ba nem irta bele magat de amugy fut.

ugyhogy megforditanam a kerdest: mutass egy recent distrot, ami systemd alapu es nincs rajta default resolved...

Az összes fentire: jogos, Debian tényleg szarul csomagolja és a teljes systemd ernyőprojektet berakja egybe (így az összes származéka is); de használva nincsen.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

dehogynincs hasznalva:

 

root@btk-mailgw2:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
...

# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0

 

root@btk-mailgw2:~# systemctl status systemd-resolved
* systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-12-26 23:35:48 CET; 1 weeks 4 days ago

Én a sysvinit-et látom át. Az esetek 98%-ában ez tökmindegy, mert megy minden magától, de van olyan launchd elem amit 10+ éve nem bírok leírtani a gépemről. Baj mindig maradék 2%-ban van. De biztos jó csak ennyi év alatt se jöttem rá néhány dologra benne :)