HOVD 2018 - Kedvenc init rendszer

HUP

busybox
5% (24 szavazat)
nosh
0% (1 szavazat)
openrc
10% (49 szavazat)
pies
0% (0 szavazat)
procd
0% (2 szavazat)
runit
2% (8 szavazat)
s6
1% (3 szavazat)
systemd
50% (251 szavazat)
sysvinit
32% (161 szavazat)
uinit
0% (1 szavazat)
Összes szavazat: 500

( timi | 2018. 12. 28., p – 19:55 )

Ejnye, hát már senki sem akarja meggyilkoltatni Lennart Poetteringet? :)

( carlcolt | 2018. 12. 28., p – 22:32 )

A Windows-et hogy hivjak?

A macOS-et hogy hivjak?

Azok szerepelnek?

(Upstart amugy egy fontos szereplo es kimaradt)

A busybox init rendszer IS.
Amúgy kíváncsi vagyok, hogy aki a systemd-t kritizálja (mint én), mondván felrúgja a unix filozófiát, hogy vélekedik a busybox-ról? Mert az aztán tényleg egy vegyes felvágott, de valahogy mégsincs vele kapcsolatban az a visszataszító rossz érzésem, mint a systemd-vel :D

Valószínűleg azért nincs senkinek különösebb baja a BB-vel, mert egyfelől nem tolták le erőszakosan az emberek torkán, másfelől pedig ez csak pár fontosabb parancsot tartalmaz, amikből te mellékelhetsz másikat, ha akarsz és nem asszimilálta megkerülhetetlenül a fél (?) rendszert, beleértve egész alrendszereket...

Ide is írom mégegyszer: A busybox egy linuxrc és/vagy inittab alapú entitás.
Szóval nincs semmi látnivaló.
Inkább az AIX az érdekes. Van olyan szöveg, ahol választhatsz: ...vagy használod a primitív rc alapú rendszert. :-D
Ilyenkor szoktam ezt a példát felhozni: /etc/methods/cfginet
Ez ugye bármely rc-nél egyszerűbb, hiszen az egész gép le van írva egy ojjektumorientált ;) adatbázisban. Aztán a service kezelés is lehet teljes, részleges és klasszikus (signal alapú). Bármelyiket kezeli a srcmstr (resource controller). Természetesen az egész adatbázisban (AIX "registry" = ODM (object data manager)).

Azért ez a sok duma, mert a systemd-t alkotó művész nem látott még hasonló megoldást. Mégpedig olyat, amikor több évtizedes unix ismeretekkel ugyanúgy tudsz kezelni egy rendszert, mint a legfrissebb biszbaszokkal. Ehhez képest a systemd olyan, mintha holnaptól evezővel kellene hajtani az autódat. Van aki megszokja, van aki eltöri az evezőt az aszfalton. ;)

Úgy néz ki, hogy ezzel is tényleg vannak bajok. A Devuan installerében az van és ebbe is betette a lábát az a pötteringista mocsok, ami "predictable network interfaces" néven pusztítja a rendszergazdák idegrendszerét, valamint a hálózati alrendszert nem lehet vele újraindítani, mert se ifup/ifdown, se szolgáltatás, mert "majd ráhagyják a disztróépítőkre"...

Úgy, hogy többek között te szoktál vernyákolni, hogy a systemd mindent is csinál, és az nem az init dolga. Fel szokott jönni a mindenféle damontools és hasonlók pl.

Ráadásul: 


docker run -ti --rm busybox /bin/sh                                                                                                                                   ~/zmc6.0.10 
/ # ifconfig 
eth0      Link encap:Ethernet  HWaddr 02:42:AC:12:00:02  
          inet addr:172.18.0.2  Bcast:172.18.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:30 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4460 (4.3 KiB)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

/ # ifup 
BusyBox v1.26.2 (2017-05-15 21:05:54 UTC) multi-call binary.

Usage: ifup [-anmvf] [-i FILE] IFACE...

        -a      Configure all interfaces
        -i FILE Use FILE instead of /etc/network/interfaces
        -n      Print out what would happen, but don't do it
                (note: doesn't disable mappings)
        -m      Don't run any mappings
        -v      Print out what would happen before doing it
        -f      Force configuration
/ # ifdown 
BusyBox v1.26.2 (2017-05-15 21:05:54 UTC) multi-call binary.

Usage: ifdown [-anmvf] [-i FILE] IFACE...

        -a      Deconfigure all interfaces
        -i FILE Use FILE for interface definitions
        -n      Print out what would happen, but don't do it
                (note: doesn't disable mappings)
        -m      Don't run any mappings
        -v      Print out what would happen before doing it
        -f      Force deconfiguration

Nem. Vernyákolni a systemd fanboyok szoktak, amikor valaki kritikát mer megfogalmazni a systemd-vel kapcsolatban, mert képtelenek felfogni, hogy egy init rendszer arra való, hogy a szolgáltatásokat kezelje. Namármost, a hálózati szolgáltatás az nomen est omen egy szolgáltatás. Ha te ezt nem érted, akkor sajnálom.

Az, hogy a nálad lévő busyboxba valaki rakott ifup/ifdown parancsokat, az nem változtat a busybox fejlesztőjének a fentebb linkelt véleményén és nem segít azon, hogy a Devuan telepítőjében egy olyan összeállítás van, amiben nincsen.

Viszont a veled való vitákat én befejeztem, mert se időm, se kedvem nincs olyan alakokkal vitatkozni, akik csak személyeskedni képesek, ha valaki kritizálni merészeli imádatuk tárgyát.

"Some Linux distributions have deprecated the use of ifconfig and route in favor of the software suite iproute2,[3] which has been available since 1999 for Linux 2.2." (ifconfig wikipedia oldal)

Jól számolom, hogy közel húsz(!) éve...?

És ahogy nézem az ifupdown is beleesik ebbe a körbe, úgyhogy nem véletlenül hajították ki.

Azt ugye tudod, hogy az ifupdown az Debian-specifikum és nem cross-distro megoldás? Felejtsd el a használatát, mással kell menedzselni hálózati interfészt, olyan dologgal, ami használható, ha épp nem Debian elé ülsz le. Erre az ip nevű eszköz való, ip link set _interfacename_ down

Folosleges. Amig a tomegnek megy a common usecase (notebook boot, server boot), addig nem fogod meggyozni oket, hogy a systemd rossz.

Mar nincs annyi tuningolo, mint hajdanan. Pl. szoritsuk le a raspberry pi grafikus bootjat 20 sec kornyekere. Nem kell semmi, csak legyen kepernyon valami grafikus felulet (semmi halozat, semmise).

Aki ezt systemd alatt megcsinalja, annak gratulalok, egy vert pisilos feladvany, kb. vetekszik grafikai kezelofelulet megirasaval idoben...
Nekem 2 hetig tartott, es meg igy se tudtam egy csomo mindent megoldani, es csak 30-40sec koze tudtam leszoritani.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Nyilván fel lehet darabolni és ki lehet szervezni belőle a szolgáltatások kezelését, de nem szokták."
Végülis csak az AIX (Az init és a System Resource Controller két külön dolog), a Solaris (init és svc.startd két külön dolog), a Windows (crss.exe és services.exe két külön dolog). Nem véletlenül van ez így ám.

Szeméyleskedés? Nekem nem tűnt úgy, hogy a személyedet támadtam volna sosem :) Sytemd fanboynak se érzem magam (különösebben nem kedvelem, imádni biztos nem imádom)

Nézd, mint fentebb már kifejtették, az init az az init, a service management meg service management. Azt is, hogy ezek sok helyen elkülönülnek egymástól. Pl az általad említett s6 is service managementnek mondja saját magát, amit ha nagyon akarsz, be tudsz pakolni egy init helyére. Kb, érdemes lenne elolvasnod az erről szóló részt, mert elég jól leírja, hogy az init mint olyan miket csinál, amit tulajdonképpen csak ráhákoltak az s6ra.

Mindössze arra a saját kettőslátásodra szerettem volna felhívni a figyelmedet, hogy míg a systemd szerinted rossz, mert mindenféle mást csinál, mint amit kellene neki, utána busybox meg azért rossz, mert a fejlesztője le merte írni a "do one thing, but do it well" mantrát, -- ami szerinted ugye az üdvözítő út -- network kezelése kapcsán. Érvnek ugyanis kicsit gyenge az ezek eddig is össze voltak nőve, tehát ha szétszedi valaki az rossz :)

Az, hogy a nálam levő busyboxban meg van, ez ebből tök mellékszál, csak mutattam, hogy egyébként benne van. De muszáj megemlítenem, hogy az egy offical docker busybox image, ők meg nem szoktak bele patchelni dolgokat (különösen nem olyanokat, amikre dockerben semmi szükség nincs, márpedig az ifupdown ilyen), szóval azt bizony a busyboxosok tették bele, és a devuanos barátaid (vagy az upstream debian) szedték ki belőle (valószínűleg épp azért, hogy ne ütközzön a saját ifupdownjukkal), szóval nem annyira érdemes emiatt a busyboxot minősíteni.

Más baja is van. A busybox nem csak Init rendszer, hanem minden egyben. Meg minden IS. Ezért aztán ha valami nem megy, akkor képtelenség rájönni, miért. Pl. mostanában nekem két különböző platformon sem ment az "udhcpc". De a "dhclient" meg ment. Nem bírtam rájönni, mi rontja el az "udhcpc"-t.

Fogalmam sincs, azoknal hogy hivjak. De mi a Linuxos registry neve? Ha valami nem ertelmes adott rendszernel, akkor nem az, nem kell szavazni. Ahogy en sem szavazok kedvenc BSD-re, mert reg hasznaltam mar (meg Pentium II-esen probaltam FreeBSD-t, meg Freesbie-t hasznaltam valamikor gepteremben).

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

macOS esetén a launchd az első user process és a service manager is egyben.

A Windows eseten van egy darab top level process, ami minden process őse.
Ez az smss.exe (Session Manager Subsystem), azonban ez két dolgot kezel csak: winlogon.exe és csrss.exe.
A háttérszolgáltatások a Service Control Managerrel futnak (services.exe), amit a winlogon.exe indít el, és nem az init (smss.exe) része.

Szóval Windows esetén a háttérszolgáltatások kezelése és az első usermode process elkülönülnek egymástól, akár más jogaik is lehetnek, ennek minden előnyével és hátrányával.

Én néha be szoktam mondani, hogy nekem tetszik.

Ami nekem bejön benne az az, hogy deklaratívan és viszonylag egyszerűen lehet leírni a szolgáltatásokat. Illetve egyben időzítő is. Én kb ennyire használom, de erre a célra egyszerűbb mint a sysvinit+cron volt.

Például olyat bekonfolni, hogy indulás után negyed órával fusson le valami, és utána ismételgesse félóránként, ha sikertelen systemd-vel könnyű volt csinálni, sysvinittel meg bonyolultabbnak érezném.

A függőségkezelését még nem teljesen értem, arról nem tudok nyilatkozni :-). De viszonylag gyorsan indul a gép a systemdvel is.

Az upstart is jó volt egyébként, de nekem nincs arra hangulatom, hogy mást használjak mint amit a disztró alapból ad. Ezért jelöltem a systemd-t kedvencnek mert használom is és bajom sincs vele.

Tény, hogy vannak marhaságai, de működik. Nem véletlen, hogy kb. az összes nagy distro systemd-t használ.

A függőség kezelése sokkal jobb, értelmesebb a formátum. Ugyan olyan service fájlban definiálható minden. Pl. múltkor egy init scriptet akartam lefuttatni a daemonjaim előtt, ehhez kellett neki egy service fájl, meg arra egy dependencia a daemonoknál, ezután még ahhoz se kellett plusz kód, hogy csekkolja a visszatérési értéket.

> működik.

Hát ha ezt működésnek lehet nevezni...

> Nem véletlen, hogy kb. az összes nagy distro systemd-t használ.

Hát az biztos, hogy nem véletlen.

> A függőség kezelése sokkal jobb, értelmesebb a formátum.

Jobb, meg értelmesebb, mint mi? A SysVInit? Ezen is lehetne vitatkozni ugyan, de inkább csak azt mondom amit eddig is: Egy érv a SysVInit ellen még nem érv a systemd mellett; egy tonna egyéb init rendszer is van, mint ez az önhatalmúlag cselekvő, mindent asszimiláló, minden eddigi működő konvenciót felrúgó, mindennemű koncepció nélkül készülő, kiteszteletlen, instabil bugrakás. Tiszta windóztíz á la Linux, csak ez még előbb volt, mint a windóztíz. :P

( Zahy v | 2018. 12. 29., szo – 15:07 )

Nyilván én vagyok a hibás amiért nem javasoltam, de hiányolom a classic BSD-init-et. Ami nem csak a systemd-től, upstart-tól, de még a sysvinittől is eléggé távol áll (mert ugye sem célok, sem futási szintek nincsenek benne, össz-vissz a single-user + multiuser ( + halt) állapot. Mindegy, ebből a készletből is tudtam választani, bár jó pár versenyző nevét se hallottam.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Naprakészre frissített Debian-alapú rendszeren használok olyat, hogy a "gyári" sysvinit csomagból csak a /sbin/init és a /etc/inittab van feltéve, az inittab pedig ennyit csinál:

runlevel 1-5 -> /etc/rc
runlevel 6 -> /etc/rc.reboot
runlevel 0 -> /etc/rc.shutdown

Nevezzük funkcionálisan kvázi BSD init-nek... :)

Van még olyan "korszerű" oprendszer, ami klasszikus BSD init-et szállít?

Egyébként, ha nem valami beágyazott rendszerről van szó, a mai "sokkomponensű" világban az openrc vagy a sysvinit rugalmassága igen kellemes tud lenni.

Én személyesen nagyon szeretem az aktuális NetBSD verziókban lévő init rendszert. Eddig nem tudtam, hogy azt hívják OpenRC-nek, de mostmár azt is tudom, és arra is szavaztam.

Az jó, ha jön az OpenRC a Linux disztribúciókba, meg az is jó, ha marad a mellette még a SysV is alternatívának. Ugyanakkor: hiába lehet pl. Debian-on egy mozdulattal visszatérni a legtöbb esetben a sysvinit-re, ha az egyes $foobar csomagokból kidobják a hagyományos rc szkripteket és csak systemd unit fájlokat szállítanak. Akkor lehet újra "csináld magad" mozgalomban rendszert építeni, mint 1994 környékén.

( TCH | 2018. 12. 29., szo – 23:22 )

Kellett volna egy olyan opció, hogy mindegy, csak ne systemd...

( r3flow | 2018. 12. 30., v – 14:10 )

Nekem bevált a systemd. Otthoni gépemen egyetlen dologba akadtam bele csak: a bootoláskor rc.local-ból (tudom, tudom, de a megszokás...) vmrun-al vagy menet közben kézzel indított vmware (workstation) guest(ek) automatikus suspendelése shutdownkor. Hiába írtam rá service fájlt, mire oda jutott a systemd a vmware-vmx processzeket már rég legyilkolta killel. Korábban sysvinit-nél ez működött. De aztán (részben) megoldódott, a systemd logind működése az oka. Ami amúgy tök jó, csak nem mindig kényelmes. :) A systemd-cgls eredménye adta a megoldást. Kiderült, hogy shutdown-kor a systemd első lépése az hogy mindennek ami a user.slice alatt van annak küld TERM majd KILL szignált és csak ezután kezdi el a system.slice alatti service fileokat "végrehajtani". Ezen nem változtat a logind.conf-ban a KillUserProcesses=no sem és felcserélni sem lehet a két lépést, ahhoz patchelni kéne a systemd-logind-t. rc.local-ból vagy simán user/root parancsorból kézzel indítva minden a user.slice alá kerül (nohuptól és minden mástól függetlenül). Lehet, hogy ez így valahol le van írva szépen a dokumentációban is, de természetesen nem olvastam végig az egészet. :)

A megoldás tehát hogy az rc.local felejtős (tehát most leszoktam róla) az indítást is a service fájlból kell megtenni így az ehhez tartozó a vmware-vmx processz a system.slice alá kerül így shutdownkor túléli a systemd-logind atombombáját. Ez azt is jelenti, hogy a kézzel indított VM-ek automatikus leállítására nincs mód, vagyis én nem találtam módot (legalábbis olyat nem ami nem gányolás és nem kerüli meg a cgroup-ot), azokat a systemd-logind shutdownkor legyilkolja ha elfelejtem suspendelni kézzel. Ez alapvetően csak az otthoni gépemet érintő probléma, ezt leszámítva nincs bajom vele. Kényelmesebb mint a sysvinit, a timerek is kényelmesek.

( mauzi v | 2018. 12. 30., v – 14:11 )

Muhaha, vezet a systemd! Mindjárt kedvet kapok hozzá! :)

( the_manni | 2019. 01. 02., sze – 18:24 )

systemd, mint init rendszer nem rossz, olyan mint poettering összes többi cucca, megoldja, amit sose akartál megoldani, de ha meg akartad volna, így kellett volna. nagyobb kár, hogy nem init rendszert csinált a systemdből hanem mindent is. nyilván átlagembert nem izgatja, amíg bele nem akad valami hibába, de aki szereti kényelmesre hackelni a rendszerét, az néha elcsodálkozik, milyen egyszerű volt megcsinálni ezt-azt pár évvel ezelőtt, és mennyit kell szenvedni most basic módosításokhoz.

"milyen egyszerű volt megcsinálni ezt-azt pár évvel ezelőtt, és mennyit kell szenvedni most basic módosításokhoz" - vagy épp milyen copás volt megcsinálni valamit sysvinit-tel (még akkor is, ha a Linuxosok többségéhez képest képben volt az ember a sysvinit filozófiájával és használatával), amit most a systemd csípőből tud. Ign, meg kell ismerni, tanulni kell, előrefelé kell lépdelni, nem pedig azon sírni, hogy milyen jó volt majomként a fán lógni...

( gyu v | 2019. 01. 13., v – 21:05 )

Amikor a szavazas modositasat lehetett volna kerni, lemaradtam, es addigra azt a topikot trey gyorsan bezarta, igy a sajat kedvencet ide hozzaszolasban jeleznem:

SMF