for (;;) pause();

Melyik szoftver tartalmazza ezt a remek kódsort? Systemd természetesen.
Már vagy tíz perce sírva röhögök rajta.
Ezen kód munka közben: http://tumbli.kodfodrasz.net/post/111742342905/systemd-ujabb-floss-sike…

Köszönet: ggergely @ #nohup

( sj | 2015. 02. 22., v – 20:42 )

az a baj, hogy nem latjatok, amit minden devel csavo lat itt a hupon, hogy mekkora kiralysag, ha a rendszer 3 sec alatt bebootol. Az meg nem szamit, hogy a systemd egy fostalicska.

Amikor Torvalds lebaszta ezt a gyokeret, mar lehetett sejteni, hogy ez egy bjutifulfrendsip lesz. Csak azt nem ertem, hogy a redhat, ami elmeletileg egy enterprise disztro, az megis milyen minosegellenorzest alkalmaz Poettering munkajara? Es ha a systemd-re kb. semmilyet, akkor milyen lehet a rendszer egesze?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

( deje | 2015. 02. 22., v – 21:14 )

Atyaúristen. util.c, ~8000 sor, 250kb, 1 DB forráskód fájl. Ami még azonnal feltűnt, az a két soros, kapcsos zárójel nélküli if. Emlékszünk az Apple-féle openssl bugra, ugye?
Eddig csak mások véleményei és a leírások alapján próbáltam oldalt választani a systemd ellen van mellett. Ezek után biztosan nem a systemd pártján leszek, ebből a szoftverből nagyon (!) sokára lesz csak stabil valami. És pont annyira stabil, mint amennyire secure az openssl :)

ebből a szoftverből nagyon (!) sokára lesz csak stabil valami.
ÁÁÁ... soha. Ahhoz egy csöppet le kéne állni a 625-ödik új (senkinek nem kellő, de a meglevő szoftverek működését alapjaiban szétverő) feature belefejlesztésével, és helyette stabilizálással valamint némi design cleanuppal kéne foglalkozni.
---
Régóta vágyok én, az androidok mezonkincsére már!

De akkor melyik init rendszert?

Eddig sose neztem ra tuzetesebben, de az upstart se "volt" sokkal jobb a systemd-nel.
Azt hittem az arch linux valami jobbat hasznal. Egyedul az initng-t lattam, ami a regi szellembol atvesz valamit.
De ahhoz is 2 eve egy betut se irtak:
https://github.com/initng/initng/commits/master

Abban kiegyezhetunk, hogy a regi initscriptek helyett kellene valami jobb, mert van olyan alkalmazas, amihez az keves
(mobiltelefon boot, dashboard kocsikban, ahova 3sec alatti boot kell uzemszeruen, stb.)

Az biztos, hogy systemd tenyleg nehez dio, eddig barmihez hozza kellett nyulnom, kb. mindig google-znom kellett...

Majd jon Linus es ir egyet, mint a git-nel tette:-)

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

Már bocs, de ilyen gányláda kód mellett sz@romle, hogy 2 vagy 42s alatt bootol be valami. Ez nem stílushiba (bár néhol úgy néz ki, mintha python kóder írt volna C kódot), hanem igencsak jelentős átdolgozásért ordító gánykupac. Anno C-programozás alapjai tárgyból páros lábbal rúgtak volna ki, ha ilyeneket csinálok...

"gondolom mas az eredmenye assemblyben, mint while() pause();"

Viszont *ha* ezért írta így (azaz valamiért szükséges az az eredmény, amit így kap), akkor mit fog csinálni akkor, amikor az éppen aktuális fordító már nem a most épp üdvözítő eredményt fordítja? (Mert X terjesztés előrelép egy GCC N.M-re, vagy épp átáll Clang-ra, PCC-re, bármi másra.)

Első körben meg kéne nézni honnan nyúlták a systemd service kezelését. Supervisord például kísértetiesen hasonló, docker-esek, python-osok eléggé szeretik is.

De igazából egy {journald,tmpfilesd,firewalld,machined,consoled,logind,networkd,timezoned,dhcp-client,ntp-client,dhcp-server,dns-server,http-server...}-mentesített systemd-ből is ki lehetne indulni, és elkezdeni kireszelni, hogy
- ne legyen tele az egész rendszert szétfektető bugokkal
- le bírja fedni rendesen a jelenlegi használati eseteket
- kiegészíteni olyan feature-ökkel, amik szorosan kapcsolódnak a service managementhez. Pl normális watchdog (amit pl a monit tud), service pool kezelés (amit a supervisord tud), cluster resource management integráció (de csak a service kezelést végezze, a vezérlés maradjon a cluster suite-nél)

és amíg ez nincs rendben, addig minden egyéb szart elfelejteni.
---
Régóta vágyok én, az androidok mezonkincsére már!

( saxus | 2015. 02. 23., h – 11:44 )

Sub.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( PaXTeam | 2015. 02. 26., cs – 18:04 )

az igazan szanalmas az egeszben az, hogy szemmel lathatoan az egvilagon senkinek sincs fingja sem arrol, hogy igazabol min is hoborog/rohog/stb.

1. a freeze() akkor hivodik meg, amikor a systemd/init processze fatalis hibat eszlel (SIGNALS_CRASH_HANDLER, de ugye ezt csak az ismetles kedveert kellett kiirnom, mert minden fenti okostojas termeszetesen mar reg elolvasta es megertette a forraskod ezen reszet). a vegtelen ciklusban futo pause() egy jo modszer arra, hogy ne porogjon foloslegesen a processzor (azt ugye nem kell megmagyarazni, mi a celja a freeze-nek es mit csinal a noreturn attributum?).

2. a freeze helyett vegre lehet hajtatni tetszoleges programot a fatalis hiba eszlelesekor, l. system.conf/CrashShell (meg CrashChVT), tehat a reboot is megoldhato, ha az ember nem akarja debuggolni ott helyben (es van DumpCore opcio kesobbi analizishez).

szoval hajra hupperek, hozzatok csak a szinvonalat ;).

Annó olyasmit tanultam, hogy egyetlen programnak van joga feltétel nélküli végtelen ciklusban pörögni, a kernelnek. Meg olyasmit is, hogy a függvények visszatérési értékét vizsgálni szokás. T'om ez volt már vagy 20 éve és azóta sokat változott a világ.

Hogy miért gány a fenti megoldás: A pause visszatérési értéke -1, ha a hívó processz vagy szál terminálásra kerül vagy az adott szignált kezelő függvény visszatér. Bizony, ebben az esetben is visszatérhet a pause, ami aztán vizsgálat nélkül pörög tovább. Pedig ezeregy dolgot lehetett volna csinálni. pl. vizsgálhatná, hogy a crasht kiváltó állapot fenállását, vagy az azt kiváltó okot. Vagy ne adj isten újra lehetne indítani az egészet. Oh, wait...

Szoftver tervezésnél ugye szokás foglalkozni a egy adott állapot kezelésével és annak kihatásaival. Itt azonban szimplán emo lesz a kód és befordult. Ezt még csak el lehet nézni az én szintemen álló, hello.c-nél, de itt egy kibaszott init rendszerről van szó. Ha mást nem is, de annyit kutya kötelessége lenne tenni, hogy szól a tőle függő processzeknek, hogy "Béláim! Túltoltuk!". Az eredetileg közölt cikkben is ez okozta a problémát, hogy a nagy befordultsága miatt vidáman bezombultak a tőle függő processzek. Az általad közölt CrashShell (https://github.com/systemd/systemd/blob/e410b07d2aa64a653bc0e93b77856af…) "ez ellen nem véd", mert ugyan indít egy shellt, de utána ugyanúgy freezebe megy.

Ezek mind csak az én magánvéleményeim amik, lévén csak egy villanyszerelő vagyok, nem sokat jelentenek.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Annó olyasmit tanultam, hogy egyetlen programnak van joga kondicionálatlan végtelen ciklusban pörögni, a kernelnek.

eloszor is ha kernelrol beszelunk (tehat a kontextus valami vedett modban futo kernel kod meg kulonbozo userland programok alatta), akkor a kernel nem 'program'. ha MS-DOS-ra gondolsz, akkor ott valoban minden egy privilegium szinten volt, tehat nem volt ildomos lefoglalni a procit. kernel/userland felosztasnal semmi elvi gond nincs, ha egy userland processz porogni akar. a gyakorlatban energiat zabal, ezert tovabbra sem ildomos.

masodszor a freeze() nem kondicionalatlan vegtelen ciklus, de lasd alabb.

> Meg olyasmit is, hogy a függvények visszatérési értékét vizsgálni szokás. T'om ez volt már vagy 20 éve és azóta sokat változott a világ.

szokas akkor, ha van ertelme. az adott esetben nincs ;).

> Hogy miért gány a fenti megoldás: A pause visszatérési értéke -1, ha a hívó processz vagy szál terminálásra kerül vagy az adott szignált kezelő
> függvény visszatér. Bizony, ebben az esetben is visszatérhet a pause, ami aztán vizsgálat nélkül pörög tovább.

az a helyzet, hogy a pid 1 egyszalu program, nem lehet megolni (a kernel direkt szuri a SIGKILL-t), a freeze() pedig egy signal handlerbol hivodik, es (by design) nem ter vissza. mindebbol az kovetkezik, hogy a pause a gyakorlatban nem fog az eletben visszaterni, a pid 1-et orok alvasba kenyszeriti (a procin valo porges helyett). ha megis sikerulne valamiert felebreszteni a processzt (lusta vagyok megnezni, melyik szignalt kezeli az adott helyzetben), akkor is max az tortenik, hogy megy egyet a ciklus es megint elalszik (MS-DOS vilagban ez egy cli/hlt ciklus lett volna kb.). pontosan ez a celja az egesznek, hogy a processz eletben maradjon es lehessen post mortem debuggolni anelkul, hogy a processzor porogne rajta. ez minden, csak nem "kondicionálatlan végtelen ciklus". ha az admin nem ezt akarja, akkor megvan ra a lehetosege, hogy ne ez tortenjen.

> Pedig ezeregy dolgot lehetett volna csinálni. pl. vizsgálhatná, hogy a crasht kiváltó állapot fennállását, vagy az azt kiváltó okot.

meselj, hogy lehetne mindezt megcsinalni a gyakorlatban? tegyek be a systemd-be a gdb-t meg az exploitable plugint? el tudod kepzelni, mekkora konspiraciot kialtananak a systemd utalok? ;)

> Vagy ne adj isten újra lehetne indítani az egészet. Oh, wait...

leirtam, hogyan lehet ezt trivialisan megcsinalni. oh wait...

> Szoftver tervezésnél ugye szokás foglalkozni a egy adott állapot kezelésével és annak kihatásaival. Itt azonban szimplán emo lesz a kód és befordult.
> Ezt még csak el lehet nézni az én szintemen álló, hello.c-nél, de itt egy kibaszott init rendszerről van szó. Ha mást nem is, de annyit kutya kötelessége
> lenne tenni, hogy szól a tőle függő processzeknek, hogy "Béláim! Túltoltuk!".

azt vagod, hogy a crash() akkor hivodik meg a gyakorlatban, amikor kb. fatalis memoria korrupcios hiba keletkezik a pid 1-ben? szemely szerint en mar azt is soknak tartom, amit a mostani kod csinal, nem hogy meg elkezdjen mindenfele processzekkel kommunikalni. te sem sok rendszert terveztel, az biztos...

> Az eredetileg közölt cikkben is ez okozta a problémát, hogy a nagy befordultsága miatt vidáman bezombultak a tőle függő processzek.

es mindez admin hiba volt.

> Az általad közölt CrashShell (https://github.com/systemd/systemd/blob/e410b07d2aa64a653bc0e93b77856af…)
> "ez ellen nem véd", mert ugyan indít egy shellt, de utána ugyanúgy freezebe megy.

azt ugye erted, hogy a pid 1-tol nem normalis az, hogy fatalis hibat tartalmaz. tehat ha megis bekovetkezik, akkor az kb. a vilag vege allapot (a kernel is elpanikol, ha a pid 1 kilep ugye). a systemd fejlesztok erre az allapotra irtak kodot, ami kepes rebootolni is meg post-mortem debuggolast is lehetove tenni. az admin feladata eldonteni, hogy melyiket szeretne. az RTFM hianya meg nem a systemd fejlesztoinek a problemaja. meg ugy altalaban is.

ugy altalaban meg eleg ciki, ahogy a sok okostojas itt porgott a pause-on alapulo vegtelen cikluson anelkul, hogy a leghalvanyabb fingja lett volna arrol, hogy mi a kontextus, mi a kod celja, es milyen alternativakat kinalt a rendszer a problema elkerulesere. neked is eleg lett volna annyit mondanod, hogy bocsi, balfasz voltam, es azelott nyilatkoztam, hogy elolvastam volna a kodot. de nem, neked tovabbra is all a fasz es mondod az okosat. de hajra hupperek, toljatok csak tovabb a hulyeseget.

"masodszor a freeze() nem kondicionalatlan vegtelen ciklus, de lasd alabb."
Kérlek, mi a freeze végetérésének a feltétele, és milyen a visszatérési értéket ad?

"azt vagod, hogy a crash() akkor hivodik meg a gyakorlatban, amikor kb. fatalis memoria korrupcios hiba keletkezik a pid 1-ben? szemely szerint en mar azt is soknak tartom, amit a mostani kod csinal, nem hogy meg elkezdjen mindenfele processzekkel kommunikalni. te sem sok rendszert terveztel, az biztos..."
Valóban, már a mostani kód is sokat csinál, és azt is rosszul. Egy ilyen mérvű hibánál, nem hagyjuk lógva a rendszert.

"leirtam, hogyan lehet ezt trivialisan megcsinalni. oh wait...", "es mindez admin hiba volt."
Egy init rendszernél ne a usernek kelljen ezt reszelnie. Ez megint tervezési rész, a systemd fejlesztői az egyszerűbb megoldást választották. Egy rendszerkritikus program kihalása esetén, ne egy köztes állapotban hagyja a rendszert, mert ez biztonsági szempontból igencsak gáz. Pl. jelen esetben ki tudná biztosítani azt, hogy egy folyamatosan respawnoló kód nem zabálja fel az erőforrást és nem borítja fel a bilit úgy, hogy utána az távolról kihasználható lesz?
Igen, az adminnak legyen joga magát szivatni, de ne az legyen az alapbeállítás.

A pause() itt csak a jéghegy csúcsa.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Kérlek, mi a freeze végetérésének a feltétele, és milyen a visszatérési értéket ad?

ostoba kerdes, a freeze nem ter vissza, by design. amikor "kondicionalatlan vegtelen ciklus"-rol regeltel (amit stikaban atirtal kozben "feltétel nélküli végtelen ciklus"-ra, nem mintha sokat szamitana ;), az egy ertelmetlen felvetes volt, mivel a vegtelen ciklus vegtelen, nincs kondicioja a kilepesre. az egyetlen ertelmes lehetoseg az ertelmezesre az, hogy a cikluson *belul* van-e valami feltetel, es a pause() pontosan ezt csinalja. ha most azon porogsz (pun intended ;), hogy a freeze-ben levo ciklus vegtelen es elvileg soha nem er veget, akkor magad szivattad meg, mert te mondtal total ertelmetlen dolgot, en csak probaltalak megmenteni az egyetlen ertelmes ertelmezesi lehetoseggel. de ha nem, hat nem, ertelmezzuk a hulyesegedet a helyen.

> Valóban, már a mostani kód is sokat csinál, és azt is rosszul. Egy ilyen mérvű hibánál, nem hagyjuk lógva a rendszert.

mi a rossz pontosan? a default viselkedes (amit a systemd/distro/admin emberek hataroznak meg)? vagy a teny, hogy egyaltalan probalnak valami lehetoseget adni post mortem analizisre?

> Egy init rendszernél ne a usernek kelljen ezt reszelnie. Ez megint tervezési rész, a systemd fejlesztői az
> egyszerűbb megoldást választották.

mi az egyszerubb valasztas? egy exit lett volna az, nem a coredump/rescue shell/tetszhalott allapotban tartas.

> Egy rendszerkritikus program kihalása esetén, ne egy köztes állapotban hagyja a rendszert,

milyen koztes allapot? ezzel az erovel a rendszer mindig valamilyen koztes allapotban van ;).

> mert ez biztonsági szempontból igencsak gáz.

meselj, mit lehet kezdeni egy freeze-ben 'futo' processzel?

> Pl. jelen esetben ki tudná biztosítani azt, hogy egy folyamatosan respawnoló kód nem zabálja fel az erőforrást és nem
> borítja fel a bilit úgy, hogy utána az távolról kihasználható lesz?

mi koze egy respawnolo kodnak meg ez eroforrasok felzabalasanak (itt nem vilagos miyen eroforrasra gondolsz amugy) a freeze-hez? ugy van, semmi.

> Igen, az adminnak legyen joga magát szivatni, de ne az legyen az alapbeállítás.

ha az a bajod, hogy a nem-admin kepessegu felhasznaloknak rossz a default valasztas, akkor lehet menni panaszkodni a systemd/distro/admin emberekhez a valasztassal kapcsolatban. de mindez fuggetlen a kodtol, amit fikaztal, es amirol meg mindig nem derult ki, hogy mi a baj vele. ugy latom, hogy a sirva rohogesbol atmentel gorcsos erolkodesbe.

"a default viselkedes (amit a systemd/distro/admin emberek hataroznak meg)?"
Ez. Fussunk még pár kört azon, hogy egy rendszernél milyen elvek mentén szokás a default viselkedést megtervezni?

Mi az egyszerübb? for (;;) pause(); vagy egyenként megvizsgálni a processzek függőségeit, azokat egyenként leállítani, majd újraindítani a rendszert? A probléma, hogy a default mellett választható két opcióban is freeze() a móka vége. Igen boldogító, hogy kaphatok shellt, mikor a rendszer egy oszlop tetején van a usertől 1500km-re.

Tehát a freeze();-ben való pörgés közben teljes mértékben képes ellátni a systemd a feladatát? Azért köztes állapot, mert még fut a processz, de a feladatait képtelen ellátni. Remek feature egy alapvető feladatokat ellátó processznek.

A freezeben lévő processzel semmit nem lehet kezdeni, az összes többi futóval, ami függ tőle annál inkább. Lásd: sshd respawnt. És a respawnak a systemd freezebe történő merevedése az oka. Nem?

Ha nem jött volna le, nem a két sornyi kóddal van a probléma, hanem az adott problémára adott válasszal és az ahhoz használt eszközökkel. Erőlködés? Legfeljebb akkor lesz, mikor ezen, nem-admin képességű felhasználóknak rossz default választással tervezett rendszer miatt kell majd cserélnem komplett egységeket. Viszont, ezen erőlködésekért fizetnek.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "