( kroozo | 2020. 10. 10., szo – 17:11 )

> Azt kértük, olyat mutass, amit csak a systemd tud.

Mutattam is. Meg mást is, elnézést, hogy nem úgy ugrálok, ahogy te fütyülsz.

> Oké, akkor pontosítok, hogy mire gondoltam: a systemd bináris loggolása agyrém. System-service-ek kimenetét loggolja binárisan, mert csak.

Nem mert csak, hanem a bináris logolás előnyei miatt. Pl, hogy a systemctl status kiementében gyorsan meg tudjon jelenni a unit naplójának a vége, vagy hogy lehessen értelmesen unitra, vagy időpontra szűrni anélkül, hogy mindjuk ki kelljen találnom, hogy hogyan lehet lefedni a timestampeket regexel, amik tegnap délelőtt 9 és 11 között készültek. Értem én, hogy szerinted fontosabb, hogy text file legyen, mert hatalmas tragédia találni valahol egy journaltclt, és odadni --fileal, mint simán csak catoln, és edge casekben (file corruption) jobban viselkedjen. De ezek vitatható szempontok. Szerintem elég baromság renszert edge casekre tervezni, de én el tudom fogadni, hogy neked az úgy jobb. Csak ettől még nem lesz a bináris logolás agyrém.

Ja, és effektív a system logot, nem csak a servicekét. Vagy egyébként szerinted a sima syslog mit logol?

> Text. Jól tömöríthető, ha annyira sok helyet foglal.

Akkor most próbáld meg még egyszer értelmezni, hogy mit mondtam.

> Tehát, ha csak egy példát hozok, hogy szar, akkor csúsztatok, de ne hozzak több példát, mert inkább elhiszed, hogy van? Izé... Hogy is van ez?

Nem, csúszatni akkor csúszatsz, amikor úgy tálalod azt a reportot, hogy az állításaid nem igazolja. És azért írtam, hogy tekintsünk el tőle, mert mint mondtam, elhiszem neked, hogy találsz még az interneten esetet.

> Bakker, épp most pirítottál rám, hogy ne hozzak több példát a korrumpálódásra, mert elhiszed, hogy van még... Most akkor hozzak, ne hozzak, bizonyítsak, vagy inkább mégse? Döntsd már el.
> De tessék: volt rá példa, hogy reprodukálhatóan egy reboot elég volt ahhoz, hogy kinyírjaValakinek az oldotta meg a korrumpálódást, hogy kikapcsolta a logok tömörítését. De a fő, hogy Pötyi korrekt összefoglalást adott és rotálnak, ha kell, helyén van a damage control... Ne fárassz már. :)

Azt az állításodat kellene bizonyítani, hogy a legkisebb sérüléstől teljesen olvashatatlan lesz. Én még tettem rá egy hevenyészett teszet is, amiből az látszik, hogy ez az állításod nem igaz. Pötyi leírása szerint jó eséllyel az állításod nem igaz. Ez a két link erről semmit nem mond. Fogalmunk sincs, mennyire olvashatatlanok azok fileok. Az első ráadásul elolvasva vagy eleve fs driver bug volt, vagy -- ami valószínűbbnek tűnik -- ugyan systemd, de a log file corruption csak byproduct volt, sima text fileal is ez történt volna. A második meg a benne levő információkból csak annyi derül ki, hogy valami compression issue volt, nem sok köze van neki a minimális korrumpálódáshoz. Ráadásul ez mindkettő sima bug, amiről magad mondtad, hogy nem para. Ami bugreport, az egészen úgy tűnik, hogy javult, ráadásul függetlenül.

> Ebben igazad van, de ki mondta, hogy feltétlenül gzippel tömörítsd a szöveges logokat? FS szintű tömörítés is van, hibakezeléssel. Persze atomtámadás ellen az sem véd, dehát semmi sem tökéletes.

Ne haragudj, hogy azzal hasonlítottam, ami jellemzően van egy standard setupban. 

> És akkor itthagynék egy linket, amiben leírják, hogy a metaadatok loggolását a systemd nem konzisztensen csinálja, mert nem bírja cérnával a rendszer:

Hagyd, de ne haragudj, ennyire nem érdekelnek a random iderángatott bugok, amiket találtál a bináris loggolással kapcsolatban, mert biztosan bármeddig tudod citálni. Biztosan az egész egy rakás szar, kész csoda, hogy van, akinek néha még van valami logja. És ettől rögtön a bináris logolás agyrém is lesz. Nekem nincs kedvem beszélgetni valamiről, amit eleve nem is én hoztam fel, és azzal nyitottam, hogy vannak előnyei meg hátrányai, és nem biztos, hogy jó ötlet volt defaultba tenni. Miről akarsz még megygyőzni?

>> Már most azon lovagulunk, hogy az execline nem shell script? Kérlek, a deklaratív vs script vonalon maradjuk. A systemdben effektív iniket kell írni.

>Itt meg envdirek vannak, envfile-okkal. Mi a baj vele?

>> Ami szabad fordításban azt jelenti, hogy nem kaptál megoldást. Amiket ajánlanak, azok jellemzően scriptek.

>Az ajánlás nem szentírás. Megírhatod Lua-ban is, vagy bármi másban.

Az, hogy nem is érted, mit akarok mondani, Az s6-envdir simán csak a child futtatási környeztét állítgatja. Az összes többit neked kell lescriptelned.  A unit fileok meg az egész rendszer működését így csinálják, nem kell neked semmit megírni, mert meg van csinálva. A nem kaptál megoldást, pontosan ezt jelenti: hogy nincs kész, neked kell megcsinálni.

> Fenéket. A shellscripttel ugyanúgy részegységeket lehet összekötögetni, mint bármelyik másik scriptnyelvvel. Ettől csak flexibilisebb lesz a rendszer. A systemd-sek kikiáltották a shellscriptet a sátán művének, az a patásscript. :P

Pontosan ezt magyarázom, hogy tök mindegy, hogy melyik másik program nyelven kell csinálni, az azt jelenti, hogy neked kell implementálni, mert programnyelv. Ehhez képest, a systemd -- jót, rosszat, sokat, keveset -- de kész megoldásokat ad a kezedbe, amiket csak fel kell konfolni.

> Ne fölényeskedj, hanem nyisd ki a systemd bugtrackerét.

Publikus projektek bugtrackerének nézegetésével maximum a dolog elterjedtségére lehet következtetni. 

> A nagy túrót. Olvasd el, mi minden van még benne. (Pl. s6-supervises6-notifyoncheck

Hm, egyrészt köszi a linket, hogy ez mennyivel jobb, mint az s6 saját doksija. Abban igazad van, hogy elfelejtettem, hogy bele lehet írni a dependencyket egy fileba is, de sajnos az, hogy itt lényegében csak egy oda vissza transitive gráf van, nem változtat.

> Mint te az s6-ot. De ezt a részt valóban nem néztem még, majd lecsekkolom.

Ne haragudj, de de. Én azért néztem az s6ot, szeretem is az s6ot, van is, hogy használom az s6ot. 

Egyrészt azt nézd meg, hogy hány féle típusú dependencia típus van, Illetve ez azért érdekes (az, hogy konkrétan párokban van), csak hogy érts, mert mondjuk egy saját unitból is meg tudom mondani, hogy egyébként baszki mostantól az sshd dependál rám anélkül, hogy hozzá kellene nyúlnom az sshd distró által szállított konfigjához. Ugyan mivel a systemd lehetővé tesz overrideolt paramétereket (amiket szintén azért tud, mert deklaratív), ez tulajdonképp menne másképp is, de pl az s6ban ez már szívás. És ha az s6 a rendszer managere akkor ez kellemetlen. 

> Nem kell "raceconditionözni" Watson, rendesen kell megírni. Nekem valahogy sikerült. És ez is elfedi az "agyrém gányolást" és nincs race condition. És működik minden UNIX alatt. (És egyébként itt szólok, hogy az általad említett double fork egyáltalán nem szükséges, a cikkemben erre is kitértem.)

Dehát pontosan ez az, hogy a fasznak feltalálni a spanyol viaszt minden egyes daemonban. Nyilván te is azért nem csináltál double forkot, mert direkt ki akartál cseszni magaddal, hiszen az egy jó dolog.

Race condition fronton meg: "Generally, to send a signal to a daemon, you need to know its PID. Without a supervision suite, knowing the proper PID is hard. Most non-supervision systems use a hack known as .pid files, i.e. the script that starts the daemon stores its PID into a file, and other scripts read that file. This is a bad mechanism for several reasons, and the case against .pid files would also justify its own page; the most important drawback of .pid files is that they create race conditions and management scripts may kill the wrong process." -- remélem sknak elhiszed.

> De könyörgöm, ez a normális megközelítés.

Akkor mit szerettél volna mondani?

> Vékony minimum a francokat, olvasd el rendesen.

Mármint te a mondatomat. Az s6 cli interface vs a mindenfélectlek interface. Ez utóbbi lényegesen több kényelmi segítséget ad. (És persze, ez megint szubjektív)

> Egyik sincs kizárva. Fejtsd ki bővebben, hátha érteni fogom és akkor kiderül.

Hogy segít nekem ez megoldani azt, hogy ha konnektálok a céges openvpnre, ami split tunnel, és csak a 10.akármit viszi be csak az .encegem domainbe tartozó dns query menjenek be a céges dns szerverhez, a pornhub pl továbba se.

Erre gondolsz?

Erre gondolnék, ha használná a cgroupsot, de sajnos nem teszi még, amennyire én tudom, az meg sajnos azért egy fokkal jobb mechanizmus.. (És még mielőtt nekiugranál, biztos, hogy lehet valami wrapperrel indítani az s6ból, ez biztos benne is van valamelyik összefoglalóban, és biztos igaz is)

Olvasd el a tmux fejlesztőjének az indoklását.

Ja, ez volt az. Ez egyébként nem a readines notificationról szól, de mindegy is. Szóval az van, hogy a systemd hozott egy featuret, hogy szabályozza, hogy a userek ne hagyjanak maguk után long running szarokat, nohuppal meg isten tudja mivel (meg mellé eszközöket, amivel ezt lehetne szebben csinálni). Természetesen lehet azon agonizálni, hogy ez az egész egyáltalán minek. Én azért tudok rá nem kevés usecaset mondani, akinek nem tetszik, továbbra is ki tudja kapcsolni, btw, a distrok nagy része mégsem teszi, szóval szerintük se olyan rossz ötlet ez. Szóltak a tmuxnak, mint tipikus usecasenek, akit érinthet, hogy ugyan a user simán el tudná intézni jól indítva, de esetleg lehetne neki jobb. Ők meg közölték, hogy ők be nem emelnek semmifélre új platform specifikus kódot. Lelkük rajta, ő dolguk, de én itt a nagy igazságot nem látom. Ráadásul a tmux egy igen speciális eset, egyike azon kevés programnak, amiknek tényleg az a primary usecase, hogy egy interaktív user nevében fussanak, mikor az nincs belépve.

> Másképp. Eddig mindennek, amit felhoztál, volt megfelelője az s6-ban. Max. neked nem tetszett. Nekem meg a systemd nem tetszik.Itt viszont tőlem okosabb ember írt egy nagyon részletes összehasonlítást az s6 vs. systemd témában, ahol kitér a leglényegesebb dolgokra, meg a végén a mítoszokra is, amivel a systemd evangelisták szoktak ködösíteni.

Egyrészt nem, csak nem érted miről beszélek, mert sose nézted meg alaposan, meg nem fogod fel, hogy pl disztribek esetében ezek soft érvek, hogy sokkal könnyebb bizonyos usecaseket lefedni mennyit számítanak. Nem én vagyok az, aki szerint ha a systemd nem tud uniq dolgokat felmutatni, akkor szar.

Gondoltam, hogy fogod majd linkelni, mert olvastam már, és mert egy húron vagy vele. Kérlek vedd észre, hogy a táblázat nagy része erősen szubjektív, mind a konkrétumokat tekintve, mind azt az, hogy egyáltalán mit tart fontosnak. És kb ugyanaz látszik belőle, ami itt. Hogy nem akarod megérteni, hogy attól még, hogy mindkettő tud egy bizonyos featuret, attól még bizonyos szempontból lehet az egyik jobb, mint a másik. (És máskor meg fordítva)

> Kezded kapisgálni. Igen, ha át lenne zúzva egy csomó dolog a PID1-ből más processzekbe, akkor mindjárt negyedennyire lenne szar a systemd, mert nem tenné sokkal sebezhetőbbé (nem (csak) biztonságról van szó: stabilitásról, hibalehetőségekről) a rendszert; ha a PID1 összedől, vége a rendszernek. Ismét tőlem okosabb ember véleménye a kérdésben.

Te még nem :). Hidd el, értem én, hogy ha a pid1 megáll, akkor minden megáll, nem véletlen mondtam, hogy szerintem ennek lényegesen kisebb jelenleg a valódi jelentőssége, mint ahogy szeretjük előadni. In practice, ha a service manager megáll, akkor az esetek nagy részében annak a gépnek már úgy is mindegy. És ha a systemd-t úgy ahogy most van betennénk mint egyetlen plusz processzt egy egyszerű init fölé, attól ugyanúgy nagyon szar lenne, ha megállna. És ez egyébként igaz lesz egy s6 supervisorra, egy daemon toolsra,meg egyéb másokra is.

> Nem szeretnék. Nagyon sokat kéne hülyülnöm ahhoz és nem azért, mert én akkora zseni lennék, hanem mert Poettering akkora majom. A megoldásaiból, a kódjából, a viselkedéséből mind-mind ez jön le. Csak egyetlen érv ez mellett: én elismerem, ha elbaszok valamit és nem kezdek kereszteshadjáratba, hogy megideologizáljam, hogy az úgy van jól.

Aha, jól látszik ez abból, hogy mennyire vagy képes fekete fehéren nézni a systemdt. 

> (BTW, miből gondolod, hogy én nem raktam le a saját területemen semmi számottevőt az asztalra? Nem tetszik a pofám, tehát automatice hülye vagyok?)

Pont abból, ami alapján te megítéled pötyit. Abból, amekkora blődségek itt kiesnek [szerk: néha ] a szádon szakmai szempontból, meg abból, hogy mennyire vagy képes megpróbálni felfogni mások nézőpontját. Ráadásul már megint duzzogsz, ahelyett hogy értelmeznéd, mit mondtam.. Nem hülyéztelek le. Akkor hülyéztelek volna le, ha a Pötyi szerintem is hülye lenne, mint szerinted. De ez nem így van, én egy kifejezetten értelmes srácnak tartom.

 > És de, tudja. Csak nem olvastad el rendesen a manualt. (Miért ne lenne? A systemd annak ellenére sokkal elhízottabb, hogy nem tud többet, legalábbis eddig nem derült ki, hogy többet tudna: máshogy tud dolgokat, esetleg (neked) kényelmesebben, de nem többet. Azonfelül a s6 100% moduláris. Annyit használsz fel belőle amennyit akarsz. A systemd-nél minden bele van borítva a PID1-be. De jó helyen van ott, már mondtad. Kettő bekezdéssel feljebb a link, hogy miért nincs.)

.... Vagy te a systemdjét, vagy továbbra sem érted, hogy a máshogy is fontos, mert még mindig nem érted, hogy a systemd fő erőssége éppen ez a máshogy. 

> Nem csak shellből. A "szokásos" UNIX IPC-re megvannak a kiforrott megoldások minden nyelvben/környezetben. Ez ilyen direkt máshogy csináljuk, mert csak. Ami nem lenne baj, ha jó lenne, de nem az.

Mert csak, hát persze. Szakmabeli vagy, ugye nem kell elmagyaráznom, hogy a nodeok ki/be menetének egymásra dugásához képest egy busnak milyen előnyei vannak egy komplex, sok elemes rendszerben, ahol gyakran szeretnénk új elemeket kivenni, betenni, illetve új kommunikációs párokat bevezetni. Arról nem beszélve, hogy azért nem akkora tragédia ám dbus üzeneteket küldeni shellből (mármint meg kell hívni egy parancsot)

> De lehet. Ez a lényeg. Lehet. Nincs drótozva.

Éljen. Mármint persze, ez tök jó. Neked ez a lényeg. Más meg esetleg leszarja, hogy nem tud valamit kicserélni, amit nem is akar, cserébe örül egy szorosabban összecsiszolt rendszernek.

> Hát lehet, hogy nem a legjobb. Mert egy olyan laza szerkezetnél, mint az s6, ezerszer flexibiliseben kötheted össze a részeket és ennek a legnyilvánvalóbb bizonyítéka, hogy semmilyen s6 komponenst nem kötelező használni a setupban. Az s6-ot pedig ugyanúgy be lehet konfigolni bármire

Csak nem nagyon akarod felfogni az effortban meglevő különbségeket. Igen, az s6 egy tök jó, alaposan átgondolt, jó rendszer, helyenként kifejezetten elegáns megoldásokkal. Ha pontosan tudod, hogy mit kell csinálni, van időd jól megtervezni, és értesz hozzá eléggé, akkor fasza megoldásokat lehet vele építeni, de ez a flexibilitás egy csomó mindent rádhagy, illetve a lazán kapcsolt darabok épp a laza kapcsolatuk miatt egy csomó cornercase kezelést meg plusz kitalálást fognak potenciálisan igényelni. Ehhez képest a systemd ezekből egy csomóra ad konzerv megoldásokat, amiken belül a szorosabb kapcsolat miatt egyszerűbb rendszerösszefüggéseket szabatosan megfogalmazni, ha jó a konzerv, akkor kevesebb dolgod van, és jó eséllyel kevesebb bugi lesz a megoldásban, mint ha on the fly kellett volna lefejleszteni (pl sokkal kisebb esélyed van rá, hogy egy hülye, primitív shell script syntax hiba miatt szopjál az ügyfélnél) Igen, ennek az az ára, hogy nagyobb, bizonyos tekintetben kötöttebb, és van benne olyan, ami akkor épp nem kell.

És ezzel szépen körbe is értünk, innen indultam. Azt kellene megérteni, hogy ez a két nézőpont nem jobb vagy rosszabb mint a másik, hanem más. És a disztibútorok azért szeretik valószínűleg a systemdt, mert az ö szempontjaikból a good enough integrált konzerv jobb, mint egy "csak" szép tiszta alapokat adó új megoldás, mert nincs elég kezük.